AWARD  NUMBER:  W81XWH-06-2-0074 

TITLE:  A  Clinician-Centered  Evaluation  of  the  Usability  of  AHLTA  and  Automated 
Clinical  Practice  Guidelines  at  TAMC 

PRINCIPAL  INVESTIGATOR:  CAPT  Emory  Fry 

CONTRACTING  ORGANIZATION:  Tripler  Army  Medical  Center 

Tripler  AMC,  HI  96859 

REPORT  DATE:  October  2009 

TYPE  OF  REPORT:  Annual 


PREPARED  FOR:  U.S.  Army  Medical  Research  and  Materiel  Command 
Fort  Detrick,  Maryland  21702-5012 


DISTRIBUTION  STATEMENT:  Approved  for  Public  Release; 

Distribution  Unlimited 


The  views,  opinions  and/or  findings  contained  in  this  report  are  those  of  the  author(s)  and 
should  not  be  construed  as  an  official  Department  of  the  Army  position,  policy  or  decision 
unless  so  designated  by  other  documentation. 


REPORT  DOCUMENTATION  PAGE 


Form  Approved 
OMB  No.  0704-0188 


Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and  maintaining  the 
data  needed,  and  completing  and  reviewing  this  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information,  including  suggestions  for  reducing 
this  burden  to  Department  of  Defense,  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports  (0704-0188),  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington,  VA  22202- 
4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  any  penalty  for  failing  to  comply  with  a  collection  of  information  if  it  does  not  display  a  currently 
valid  OMB  control  number.  PLEASE  DO  NOT  RETURN  YOUR  FORM  TO  THE  ABOVE  ADDRESS. 


1.  REPORT  DATE  2.  REPORT  TYPE  3.  DATES  COVERED 

1  October  2009  Annual  29  Sep  2008  -  28  Sep  2009 


4.  TITLE  AND  SUBTITLE  5a.  CONTRACT  NUMBER 


A  Clinician-Centered  Evaluation  of  the  Usability  of  AHLTA  and  Automated  Clinical 
Practice  Guidelines  at  TAMC 


5b.  GRANT  NUMBER 

W81 XWH-06-2-0074 


5c.  PROGRAM  ELEMENT  NUMBER 


6.  AUTHOR(S) 

CAPT  Emory  Fry 


5d.  PROJECT  NUMBER 


5e.  TASK  NUMBER 


E-Mail:  emory.fry@med.navy.mil 


5f.  WORK  UNIT  NUMBER 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Tripler  Army  Medical  Center 
Tripler  AMC,  HI  96859 


9.  SPONSORING  /  MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 
U.S.  Army  Medical  Research  and  Materiel  Command 
Fort  Detrick,  Maryland  21702-5012 


8.  PERFORMING  ORGANIZATION  REPORT 
NUMBER 


10.  SPONSOR/MONITOR’S  ACRONYM(S) 


11.  SPONSOR/MONITOR’S  REPORT 
NUMBER(S) 


12.  DISTRIBUTION  /  AVAILABILITY  STATEMENT 

Approved  for  Public  Release;  Distribution  Unlimited 


13.  SUPPLEMENTARY  NOTES 


14.  ABSTRACT 

Purpose:  The  project  will  demonstrate  that  Clinical  Decision  Support  (CDS)  material  can  be  retrieved  from  a  central,  shared  repository 
and  executed  within  the  MHS  and  civilian  health  information  systems  to  improve  quality  of  care  through  the  use  of  reminders,  alerts, 
guidelines  etc.  The  system  design  and  approach  will  decrease  guideline  development  time  and  speed  translation  of  evidence  based 
medicine  into  clinical  practice.  It  will  decrease  costs  and  enable  multiple  stakeholders  to  work  in  an  open  content/source  environment  to 
exchange  clinical  content,  develop  and  test  technology  and  explore  processes  in  applied  CDS. 

Design:  Comparative  study  between  the  KMR  infrastructure  and  capabilities  developed  as  an  open  source,  vendor  agnostic  solution  for 
aCPG  execution  within  AHLTA  and  the  current  DoD/MHS  standard  evaluating: 

HI:  An  open  source,  open  standard  KMR  and  Clinical  Decision  Support  Engine  can  enable  organizations  to  share  domain  knowledge, 
expertise,  and  collaborate  on  efforts  to  improve  patient  safety  and  quality  of  care  using  automated  clinical  practice  guidelines. 

H2:  An  open  standard  KMR  and  Clinical  Decision  Support  Engine  can  codify  clinical  practice  guidelines  and  domain  knowledge  so  that 
they  can  be  executed  without  modification  within  a  variety  of  runtime  environments,  including  AHTLA  and  VistA. 

H3:  An  open  standard  KMR  and  Clinical  Decision  Support  Engine  can  effectively  manage  both  generic  clinical  domain  knowledge 
(guidelines,  best  practice,  etc)  and  specific  institutional  requirements  (workflow,  policy,  capabilities)  to  ensure  reliable  execution  of  a  CPG 
across  institutional  boundaries. 

Methodology:  The  KMR  project  architecture  will  leverage  the  emerging  Federal  Health  Architecture  (FHA)  group  NHIN-Connect 
infrastructure  and  its  ability  to  provide  health  information  exchange  across  a  distributed  network.  In  order  to  better  support  KMR 
integration  and  evaluation  by  the  Office  of  the  National  Coordinator,  the  KMR  team  will  coordinate  and  integrate  the  KMR  project  into  the 
Agile  SCRUM  iterative  build  and  test  process  which  is  in  use  by  FHA. 


15.  SUBJECT  TERMS 

Open  Source  and  standards  based  KMR  and  Clinical  Decision  Support  Engine 


16.  SECURITY  CLASSIFICATION  OF: 

17.  LIMITATION 

OF  ABSTRACT 

18.  NUMBER 

OF  PAGES 

19a.  NAME  OF  RESPONSIBLE  PERSON 

USAMRMC 

a.  REPORT 

u 

b.  ABSTRACT 

U 

c.  THIS  PAGE 

U 

uu 

109 

19b.  TELEPHONE  NUMBER  (include  area 
code) 

Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std.  Z39.18 


Table  of  Contents 


Page 


Introduction .  1 

Body .  2-4 

Key  Research  Accomplishments .  4-5 

Reportable  Outcomes .  5 

Conclusion .  5-6 

References .  NA 


Appendices 


7 


INTRODUCTION 

The  intent  of  this  investigation  is  to  develop  an  open  source,  open  standard,  vendor 
agnostic  infrastructure  that  will  enable  organizations  to  develop  and  exchange  Clinical 
Decision  Support  content,  tools  and  processes.  A  system  that  improves  quality  of  care 
through  reminders,  alerts,  and  guidelines  would  decrease  development  time  and 
accelerate  the  introduction  of  new  domain  knowledge  into  clinical  practice.  The  KMR 
system  will  demonstrate  the  execution  of  clinical  practice  guidelines  in  AHLTA  and 
other  modem  health  care  systems,  ultimately  decreasing  costs  for  providers  and 
improving  quality  of  care.  Five  categories  of  work  guide  this  project: 

Aim  1  Engineering  Documentation 

a)  Requirement  Analysis  and  Project  Plan; 

b)  System  Design  Specification  and  Academic  Review 

Aim  2  Implementation  Of  KMR  Infrastructure  And  Delivery  Of  Source  Code 

Aim  3  Development  of  Executable  Guidelines 

Aim  4  Runtime  Demonstrations 

Aim  5  Comparative  Evaluations  &  Academic  Publications 

BODY 

Task  1:  Preparatory  Work  For  Project  Initiation 

•  First  quarter  of  2009,  changed  Principal  Investigator  from  LTC  Do  to  CAPT  Fry  and 
forwarded  revised  Statement  of  Work  to  the  sponsor. 

•  JAVA  Engineers  C.  Matser  and  D.  DeCouteau  started  2/9/09. 

•  Revised  Statement  of  Work  dated  March  16,  2009  was  approved  by  sponsors  and 
became  effective  1 1  May  2009. 

•  Based  on  the  new  proposal  and  revised  SOW,  the  Project  title  changed  from  “A 
Clinician-Centered  Evaluation  of  the  Usability  of  AHLTA  and  Automated  Clinical 
Practice  Guidelines  at  TAMC”  to  “Knowledge  Management  Repository  (KMR)  for 
Clinical  Decision  Support  (CDS)  and  Proof  of  Concept  for  Automated  Clinical 
Practice  Guideline  (aCPG)  Execution  within  AHLTA”. 

•  Location  of  the  study  was  moved  from  Tripler  Army  Medical  Center  in  Honolulu,  HI 
to  Naval  Health  Research  Center  in  San  Diego,  CA. 

•  Project  Director:  Patricia  L.  Price  returned  to  the  project  Jun  8,  2009. 

•  JAVA  Engineers  J.  Kriseman  and  Mark  Pitman  started  June  8,  2009  replacing  C. 
Matser  who  left  the  project  May  1 5,  2009. 

•  Intellectual  Property  SOP  was  reworked  to  be  consistent  with  FHA-NHfN- 
CONNECT;  Rights  and  Special  Works  language  was  selected  and  reviewed  with 
MRMC  legal. 

•  SOW,  Budget  Sub  Award,  and  Contract  Sub  Award  with  SOADEX  completed. 
SOADEX  is  providing  professional  sendees  related  to  the  documentation  of 
functional  requirements  and  system  design  documentation,  software  quality 
assurance,  creating  UML  artifacts,  and  an  engineering  plan. 


•  A  modification  to  SOW,  Budget  Sub  Award,  and  Contract  with  SOADEX  was 
completed  allowing  SOADEX  to  provide  a  “SCRUM  Master”,  the  individual  who 
ensures  that  the  SCRUM  process  is  used  as  intended  and  to  oversee  the  iterative  build 
and  test  process.  The  Scrum  Master  began  work  the  first  week  of  October. 

•  The  SOW,  Budget  Sub  Award  and  Contract  for  the  hosting  sendees  required  to  run 
the  KMR  development  servers  was  completed  between  ASU  and  The  Geneva 
Foundation. 

•  The  SOW  and  Budget  Sub  Award  for  ASU  academic  deliverables  was  completed. 
The  Contract  for  this  work  between  ASU  and  The  Geneva  Foundation  is  awaiting 
final  ASU  signature. 

•  SOW,  Budget  Sub  Award,  and  contract  for  Medsphere  to  implement,  test,  and 
integrate  open  source  engineering  deliverables  for  the  KMR  architecture  was 
completed.  The  Medsphere  kickoff  meeting  was  held  Oct  21, 2009. 

•  CRADA  agreement  as  vehicle  for  indirect  cost  reimbursements  between  NHRC  and 
Geneva  was  replaced  with  a  MOU  between  TATRC  and  NHRC.  TATRC  will  cover 
all  CAPT  Fry  and  Patricia  Price  indirect  costs  via  MIPRS.  This  MOU  has  been 
approved  by  TATRC  and  is  pending  final  approval  by  BUMED. 

•  Dr  Fry  met  with  the  CIO  of  the  Indian  Health  Service  and  with  representatives  from 
ASU  in  May  2009  and  then  again  Oct  16,  2009.  He  secured  their  commitment  to 
prepare  for  and  then  execute  a  limited  production  trial  of  the  KMR  system  for  the 
purposes  of  conducting  usability  research.  With  that  goal  in  mind,  ASU,  NHRC,  and 
IHS  are  collaborating  on  the  creation  of  a  community  advisory  board  and  a  series  of 
focus  groups  involving  prospective  participants.  The  scope  of  this  pilot  has  yet  to  be 
determined  -  when  completed,  appropriate  IRB  submissions  will  be  prepared.  The 
final  KMR  proposal  and  SOW  were  submitted  to  Chris  Blood,  IRB  Coordinator, 
NHRC  on  Oct  26,  2009  for  review.  Current  activities  center  exclusively  on  the 
engineering  aspects  of  clinical  decision  support,  any  required  semantics,  and  the 
infrastructure  required  to  support  real-time  decision  analysis  functionality.  As  such  it 
neither  touches  nor  uses  live  clinical  data  or  systems.  A  final  IRB  determination  will 
be  obtained  once  a  patient  population  has  been  identified,  and  a  pilot  hypothesis  has 
been  definitively  proposed. 

•  Office  of  the  National  Coordinator  for  Health  IT  was  briefed  on  the  KMR  project. 
Several  Federal  Agencies  and  academic  institutions  have  agreed  in  principle  to 
contribute  requirements  and  review  KMR  designs  during  a  weekly  online  meeting 
moderated  by  CAPT  Fry  every  Thursday  morning  at  10am  PST. 


Task  2:  Preparatory  Engineering  For  Transition  To  New  Project 
Proposal  And  Modified  Statement  Of  Work 

•  The  KMR  team  staff  upgraded  the  existing  DDSS  run  time  system  originally  built 
using  Oracle  into  an  open  source  implementation  and  updated  its  MIRTH  HL7  engine 
to  latest  release. 

•  The  KMR  team  staff  implemented  a  complete  conversion  of  the  NHIN  CONNECT 
2.1  release  into  a  single  virtual  machine  image  using  Linux  and  other  open  source 
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components.  This  image  was  provided  to  FHA  as  a  reference  Linux  implementation 
for  CONNECT  customers. 

•  D.  DeCouteau  and  Dr  Fry  attended  a  REDHAT  workshop  on  the  DROOLS  rules 
engine  intended  to  be  the  core  inference  engine  in  KMR.  REDHAT  and  KMR  teams 
have  agreed  to  coordinate  their  respective  development,  ensuring  that  the  DROOLS 
implementation  in  KMR  meets  functional  and  performance  criteria  required  for 
enterprise  scalability.  This  collaboration  is  supported  in  part  by  the  Medsphere 
Contract. 

•  Dr  Fry  meet  with  Wavemaker,  an  open  source  rapid  development  tool  company,  to 
discuss  adapting  Wavemaker  to  help  create  KMR  applications.  WaveMaker  has 
agreed  to  coordinate  with  the  KMR  team  to  ensure  their  use  of  WaveMaker  for 
creating  KMR  applications  is  optimal.  First  application  to  be  built  using  WaveMaker 
will  be  MedAlert,  a  key  application  for  visualizing  KMR  notifications. 

•  Team  collaboration  wiki,  source  code  repository  and  software  defect  tracking  system 
installed  and  configured. 

•  Development,  Quality  Assurance,  and  Production  environments  for 
DDSS/KMR/NHIN  infrastructures  configured,  and  installed.  SOADEX  has  hired  a 
Quality  Assurance  expert  and  is  scheduled  to  delivery  system  test,  integration  and  QA 
plans,  November  25,  2009. 


Task  3:  -  AIM  1:  Engineering  Documentation 

The  Project  Plan  and  a  Table  of  Project  Deliverables  were  completed.  The  KMR  project 
is  employing  a  SCRUM  or  Iterative  Project  Management  methodology.  The  Scrum 
process  is  built  on  a  series  of  sprints;  the  KMR  project  is  composed  of  41  sprints, 
with  each  sprint  approximately  2  weeks  in  duration,  (see  project  plan.) 

•  May  25,  2009,  SOADEX  meet  with  the  KMR  team  to  review  requirements, 
documentation,  and  schedule.  They  delivered  a  strategy  for  completing  the 
documentation  and  for  developing  the  engineering  plan. 

•  June  5,  2009  SOADEX  delivered  functional  requirements  and  use  cases.  Weekly 
VTC’s  requirement  reviews  with  Momingside  Initiative  and  other  select  academic 
organizations  were  started  and  are  on-going  with  the  intent  of  incorporating 
recommendations  from  these  meetings  into  these  requirements  and  the  engineering 
plans. 

•  The  proposed  requirements  and  design  review  that  was  to  be  held  at  ASU  in  August 
2009  with  Momingside  Initiative  and  other  select  academic  organizations  was 
cancelled.  This  gathering  has  been  rescheduled  to  November  14,  2009,  in  San 
Francisco,  at  the  AMIA  Conference  location. 

August  14,  2009,  SOADEX  provided  a  draft  system  document  detailing  system 
architecture,  technical  capabilities,  and  configuration  requirements.  This  system 
design  detailed  a  Service  Oriented  Architecture  to  be  implemented  in  Java  using 
Open  Source  technologies  from  Sun  Microsystems. 
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Task  4:  -  AIM  2:  Implementation  of  the  KMR  and  CDS 

Infrastructure 

There  are  four  software  releases  scheduled  by  the  Engineering  Plan  -  Release  4  being  the 
final  release. 

Release  1  began  in  February  2009  and  will  complete  with  Sprint  16  scheduled  for 
November  13th'.  This  first  release  will  be  the  basis  of  the  November  14th  requirement 
and  system  design  review,  and  the  first  KMR  demonstration.  The  attached  Gantt 
chart  shows  the  Sprints  completed,  the  %  of  work  ongoing  and  the  projected  end  date 
for  each  Sprint. 

Engineering  deliverables  to  date  include: 

An  implementation  of  GUI  Service  for  the  KMR  bus 

AHLTA  data  access  services 

Provider  Inbox 

Refactored  Clinical  Decision  Support  Service 

Initial  KMR  data  repository  schema 

A  policy  and  authorization  framework  for  rule  access  control  across  distributed 
repositories 

Mirth  Event  Service  responsible  for  processing  real-time  HL7  messages. 

Bus  Orchestration  Service  to  prioritize  and  manage  access  to  clinical  services 


Task  5:  -  AIM  5:  Comparative  Research  &  Academic 

Publications 

CAPT  Fry  is  scheduled  to  host  and  present  at  a  panel  discussion  on  collaborative  Clinical 
Decision  Support  as  part  of  the  AMIA  Conference,  in  San  Francisco,  November  15, 
2009. 


KEY  RESEARCH  ACCOMPLISHMENTS 

•  Initial  system  design  required  to  deploy  run-time  rule  engine  support  for  existing 
health  information  systems.  This  was  a  major  architectural  integration  effort 
harmonizing  existing  DoD  systems  with  the  Nationwide  Health  Information 
Network. 

•  Initial  canonical  data  model,  based  on  HL7  RIM,  supporting  extraction  of 
interoperable  data  objects  from  existing  health  information  systems.  This  data 
domain  model  is  the  first  publically  available,  standards-based  data  model 
designed  to  support  all  major  EMR  vendors  and  systems.  It  defines  a  Virtual 
Medical  Record  structure  that  isolates  the  middle  tier  from  the  data  tier,  thereby 
ensuring  universal  applicability.  This  model  is  a  alarum  deficiency  in  the  HL7  3.0 
normative  release  and  will  be  submitted  to  HL7  and  associated  Standards 
Organizations  as  a  candidate  domain  model  for  the  Virtual  Medical  Record. 

•  Initial  semantic  model  to  support  interoperable  rules  and  guidelines  using  existing 
health  information  systems.  This  was  a  major  semantic  integration  effort 
harmonizing  existing  DoD  systems  with  the  vocabularies  used  by  the  Nationwide 
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Health  Information  Network.  This  work  provides  the  standards-based  foundation 
for  creating  interoperable  rules  and  logical  operations. 

•  Identification  of  initial  operational  metadata  required  to  ensure  that  clinical 
decision  support  perfonns  safely  and  reliably  across  organizational  boundaries. 
This  is  significant  ontology  definition  effort  addressing  a  second  glaring 
deficiency  in  the  HL7  3.0  normative  release  -  the  lack  of  terminologies  / 
ontologies  for  describing  clinical  tasks,  actions,  and  organizational  characteristics. 
When  completed  it  will  be  submitted  to  HL7  and  associated  Standards 
Organizations. 


REPORTABLE  OUTCOMES 

Artifacts  documenting  the  research  efforts  to  date  can  be  found  at  the  following  website: 
http://www.socraticerid.oru/wiki/documentation.  Source  code  completed  so  far  (100+ 
MB).  Available  upon  request. 

CAPT  Fry  presented  and  moderated  discussion  regarding  KMR  at  the  following  Office  of 
the  National  Coordinator  meetings: 

CDS  Consortium  &  KMR  Projects  -  5/14/09 

CDS  Collaborator  quarterly  meeting  -  8/5/09 

CDS  Collaborator  Special  Session  -  ONC  CDS  Workshop  Report  -  9/21/09 

CAPT  Fry  was  a  principle  author  to  the  paper  entitled  “The  Momingside  Initiative: 
Collaborative  Development  of  a  Knowledge  Repository  to  Accelerate  Adoption  of 
Clinical  Decision  Support”  to  be  published  in  the  Open  Applied  Informatics  Journal 
later  this  year.  This  paper  describes  the  collaboration  with  the  Momingside  Initiative 
and  the  need  for  a  knowledge  management  repository. 

CAPT  Fry  presented  and  moderated  discussion  regarding  KMR  with  the  staff  of  the 
Indian  Health  Service  CIO  -  10/16/09. 

CAPT  Fr  contributed  to  a  recently  awarded  AHRQ  grant  submitted  by  Thompson 
Reuters  and  a  group  of  Federal  and  academic  investigators  to  pursue  research  into  the 
semantics  of  interoperable  rules.  The  KMR  infrastructure  was  a  key  component  in  the 
application  as  it  enabled  the  investigators  to  demonstrate  broad  deployability  for  the 
new  research  across  multiple  health  systems. 

CAPT  Fry  was  invited  and  agreed  to  present  the  KMR  project  at  MEDINFO  2010  -  13th 
World  Congress  on  Medical  and  Health  Informatics  in  Cape  Town,  South  Africa, 
September  12  -  15,  2010.  MEDINFO  2010  is  the  premier  international  health 
informatics  event  similar  to  HIMSS  here  in  the  United  States. 


CONCLUSION: 

KMR  is  implementing  a  flexible,  open-source  solution  that  enables  healthcare  entities  to 
realize  real-time  clinical  decision  support  functionality  on  top  of  their  existing  health 
information  systems.  Our  research  to  date  has  shown  great  progress  in  designing  a  hilly 
functional  infrastructure  that  will  enable  organizations  to  meet  their  clinical  decision 
support  requirements. 
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Based  on  service-oriented-architecture  principles  and  web  service  interfaces,  KMR 
enables  individual  components  to  be  replaced  by  custom  solutions  as  long  as  they  adhere 
to  the  defined  web  service  interface  specifications  and  HL7  standards.  It  allows 
implementations  to  be  hosted  on  different  hardware  and  software  platforms,  as  well  as 
services  to  be  implemented  using  different  programming  languages  against  different 
back-end  systems. 

KMR  is  layered  upon  the  Federal  Health  Architecture’s  Messaging,  Security,  and  Privacy 
Foundation  that  describes  the  underlying  protocols  and  capabilities  necessary  to  send  and 
secure  messages  between  participants  on  the  NHIN.  This  Foundation  implements  the 
core  NHIN  Services  that  define  the  interfaces  used  to  discover  and  exchange  health  and 
health-related  information.  KMR  team  members  contributed  significantly  to  this  effort 
last  year  and  now  are  providing  the  additional  services  required  to  deploy  advanced 
decision  support  sendees,  knowledge  management,  and  workflow  capabilities  for  clinical 
and  administrative  processing  of  local  and  distributed  data.  In  general,  these  additions 
ensure  that  decision  support,  orchestration  and  workflow  management  of  the  entire 
middle  tier  is  appropriately  managed  by  the  KMR  rules  engine. 

KMR  and  its  supporting  sendees  is  essentially  an  intelligent  Sendee  Oriented 
Architecture  for  Healthcare  delivering  the  data  and  services  required  for  advanced 
clinical  decision  support  and  workflow  optimization.  It  does  so  with  particular  attention 
to  the  semantic  and  organizational  requirements  for  achieving  and  maintaining 
interoperable  health  data  exchanges,  and  extends  those  semantic  constraints  into  the 
realm  of  inter-organizational  authoring,  sharing  and  execution  of  clinical  rules  and 
guidelines.  Being  standards-based,  KMR  offers  the  first  decision  support  infrastructure 
that  promises  to  be  universally  implementable  across  the  majority  of  commercial 
Electronic  Medical  Record  systems. 

Figure  1:  KMR  Service  Oriented  Architecture  For  Healthcare  Decision  Support 
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Abstract 

The  Morningside  Initiative  is  a  public-private  activity  that  has  evolved  from  an  August,  2007,  meeting  at 
the  Morningside  Inn,  in  Frederick,  MD,  sponsored  by  the  Telemedicine  and  Advanced  Technology 
Research  Center  (TATRC)  of  the  US  Army  Medical  Research  Materiel  Command.  Participants  were 
subject  matter  experts  in  clinical  decision  support  (CDS)  and  included  representatives  from  the  military 
health  system,  Department  of  Defense,  Veterans  Health  Administration,  Kaiser  Permanente,  Partners 
Healthcare  System,  Henry  Ford  Health  System,  Arizona  State  University,  and  the  American  Medical 
Informatics  Association  (AMIA).  The  Morningside  Initiative  was  convened  in  response  to  the  AMIA 
Roadmap  for  National  Action  on  Clinical  Decision  Support  and  on  the  basis  of  other  considerations  and 
experiences  of  the  participants.  Its  formation  was  the  unanimous  recommendation  of  participants  at  the 
2007  meeting  which  called  for  creating  a  shared  repository  of  executable  knowledge  for  diverse  health 
care  organizations  and  practices,  as  well  as  health  care  system  vendors.  The  rationale  is  based  on  the 
recognition  that  sharing  of  clinical  knowledge  needed  for  CDS  across  organizations  is  currently  virtually 
non-existent,  and  that,  given  the  considerable  investment  needed  for  creating,  maintaining  and 
updating  authoritative  knowledge,  which  only  larger  organizations  have  been  able  to  undertake,  this  is 
an  impediment  to  widespread  adoption  and  use  of  CDS.  The  Morningside  Initiative  intends  to  develop 
and  refine  (1)  an  organizational  framework,  (2)  a  technical  approach,  and  (3)  CDS  content  acquisition 
and  management  processes  that  will  scale  with  growing  numbers  of  participants  and  can  be  expanded 
in  scope  of  content  and  capabilities..  Intermountain  Healthcare  joined  the  initial  set  of  participants 
shortly  after  its  formation.  The  efforts  of  the  Morningside  Initiative  are  intended  to  serve  as  the  basis  for 
a  series  of  next  steps  in  a  national  agenda  for  CDS.  It  is  based  on  the  belief  that  sharing  of  knowledge 
can  be  highly  effective  as  is  the  case  in  other  competitive  domains  such  as  genomics.  Participants  in 
the  Morningside  Initiative  believe  that  a  coordinated  effort  between  the  private  and  public  sectors  is 
needed  to  accomplish  this  goal  and  that  a  small  number  of  highly  visible  and  respected  health  care 
organizations  in  the  public  and  private  sector  can  lead  by  example.  Ultimately,  a  future  collaborative 
knowledge  sharing  organization  must  have  a  sustainable  long-term  business  model  for  financial 
support. 


A.  INTRODUCTION 


A.1  Background 

The  importance  of  computer-based  clinical  decision  support  (CDS)  is  based  on  the  many  problems 
facing  health  care,  and  the  need  for  proactive,  point-of-care,  patient-specific  approaches  to  ensure  that 
best  practices  are  adopted  [1].  Among  the  well-recognized  problems  are:  spiraling  costs  [2,3], 
disparities  of  access  and  large  numbers  of  uninsured  [4,3],  errors  and  unevenness  of  quality  [5-8],  slow 
dissemination  of  advances  [9,10],  inefficiencies  and  waste  [11,3],  fragmentation  and  poor 
communication  [12,13],  and  a  lack  of  patient-centered  care  [6], 

CDS  has  been  shown  to  be  useful  in  fostering  patient  safety,  health  care  quality,  and  cost-effectiveness 
of  care  [1],  Further,  CDS  fulfills  the  practical  need  of  health  care  delivery  organizations  to  respond 
effectively  to  programs  such  as  pay  for  performance  and  prior  authorization  for  medication  or 
procedure  orders.  Nonetheless,  successful  approaches  have  not  been  broadly  disseminated  and 
adopted  for  a  variety  of  reasons  [1],  including  competitiveness,  incompatibility  of  platforms,  lack  of 
standards,  and  under-utilization  of  electronic  health  records  (EHRs)  and  computer-based  provider  order 
entry  (CPOE)  -  major  platforms  in  which  to  integrate  CDS.  But  even  for  those  with  access  to  CDS, 
enormous,  obstacles  exist,  including  the  lack  of  (1)  sources  of  high  quality  medical  knowledge  in 
executable  form,  and  (2)  infrastructure  and  processes  for  managing  and  updating  such  knowledge  and 
integrating  it  into  applications.  Addressing  these  needs  is  very  expensive,  if  not  prohibitive,  for  individual 
organizations,  even  large  ones.  In  addition,  the  need  for  knowledge  management  capabilities  has  not 
yet  been  widely  recognized  except  within  a  group  of  larger  medical  centers  that  have  been  in  the 
vanguard  of  CDS  adoption.  Further,  standards  for  CDS  representation  and  integration  into 
applications  are  as  yet  incomplete. 

In  2006  the  U.S.  Office  of  the  National  Coordinator  for  Health  Information  Technology  (ONC)  and  the 
Agency  for  Healthcare  Research  and  Quality  (AHRQ)  commissioned  a  project  by  the  American 
Medical  Informatics  Association  (AMIA)  and  produced  The  Roadmap  for  National  Action  on  Clinical 
Decision  Support,  which  proposed  a  coordinated  approach  to  address  the  above  impediments  [14], 

The  report  recommended  a  series  of  activities  to  improve  CDS  development,  implementation  and  use 
throughout  the  United  States  to  help  enable  improvements  in  health,  and  the  quality,  safety  and 
efficiency  of  healthcare  delivery. 

There  had  been  little  evidence  to  date  that  health  care  organizations,  public  and  private,  were  willing  to 
share  knowledge  that  they  believe  gives  them  a  marketplace  advantage.  Nevertheless  this  had  been 
done  in  other  fields,  even  fiercely  competitive  ones  like  genomics  research,  e.g.,  in  terms  of 
contributions  to  GenBank  and  other  molecular  and  genetic  knowledge  bases.  To  the  extent  that  it  has 
occurred  at  all,  the  primary  sharing  of  clinical  knowledge  in  executable  form  has  generally  been  limited 
to  the  activities  of  knowledge  content  providers,  EHR  vendors,  or  user  groups  of  a  particular  vendor. 
Other  ventures  have  been  less  than  successful.  As  an  example,  the  Arden  Syntax  was  developed  in 
the  early  1990s,  and  was  adopted  as  an  ASTM  standard  in  1991  [15,16]  and  subsequently  moved  to 
Health  Level  Seven  (HL7)  in  1998;  but  a  website  for  sharing  of  Arden  Syntax  Medical  Logic  Modules 
(MLMs)  developed  at  Columbia  University  in  the  mid-1990s  did  not  get  regularly  updated,  and  is  no 
longer  available.  Arden  Syntax  has  considerable  use,  but  with  many  proprietary  implementations, 
effectively  limiting  the  extent  to  which  sharing  occurs.  A  consortium  called  the  Institute  for  Medical 
Knowledge  Implementation  was  formed  in  the  early  2000s,  and  included  health  information  system 
vendors,  academic  medical  centers,  and  professional  societies  as  members,  with  the  goal  of  creating 
shared  medical  knowledge  modules.  The  group  foundered  when  no  entity  was  willing  to  contribute 
content.  (See:  http://www.prnewswire.com/cqi-bin/stories.pl?ACCT=104&STORY=/www/storv/02-11- 
2003/0001889281  &EDATE=  for  brief  mention,  although  IMKi  website  is  no  longer  available.) 
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Further,  biomedical  knowledge  and  technology  development  continue  to  advance  relentlessly,  making  it 
impossible  for  practitioners  to  keep  up  with  current  knowledge,  or  for  organizations  to  keep  pace  by 
integrating  the  new  knowledge  into  their  own  practices.  Promising  sources  of  generally  available 
knowledge  such  as  the  Agency  for  Healthcare  Research  and  Quality  (AHRQ)-supported  National 
Guideline  Clearinghouse  (http://www.Quidelines.gov)  and  the  Evidence-based  Practice  Center  reports 
(http://www.ahrq.gov/  clinic/epc/).  and  the  Cochrane  Collaboration  Library 

(http://www3.interscience.wilev.eom/cqi-bin/mnA/home/1 06568753/  H0ME?CRETRY=1  &SRETRY=0)/ 
seek  to  establish  and  update  authoritative  collections  of  reports  identifying  best  health  care  practices. 

A  current  AHRQ  program  initiated  as  a  part  of  the  American  Recovery  and  Reinvestment  Act  (ARRA)  is 
the  promulgation  of  Comparative  Effectiveness  Research  (CER) 

(http://www.ahrq.gov/fund/cefarra.htm).  which  promises  to  further  enhance  such  efforts.  There  are 
clearly  many  policy  issues  involved,  such  as  how  to  assemble  and  organize  disparate  studies,  whether 
a  coordinating  center  should  exist,  what  its  role  in  guiding  clinical  decisions  or  influencing  health  care 
spending  should  be,  and  how  it  should  be  governed  to  ensure  appropriate  representation  of 
stakeholders  [17].  Assuming  that  a  politically  acceptable  approach  for  these  difficult  issues  is  found, 
these  knowledge  resources  would  still  not  be  made  available  in  unambiguously  executable  (or  even 
near-executable)  form. 

The  technical  issues  and  impediments  involved  and  possible  approaches  to  bridging  the  gap  between 
such  reports  and  recommendations  and  the  development  of  ready-to-implement  CDS  are  elaborated  in 
the  AMIA  Roadmap  call-to-action  [14]  and  in  the  book  by  Greenes  [1],  One  attractive  possibility  that 
was  highlighted  in  the  call  to  action  is  the  idea  of  developing  a  Web-accessible  repository  of  high  quality 
medical  knowledge,  in  an  unambiguous  form  that  can  be  used  as  a  basis  for  implementing  CDS,  and 
that  would  be  available  to  all  institutions  and  users.  This  would  avoid  the  need  for  each  organization  to 
duplicate  the  effort  of  creating  and  maintaining  such  a  repository.  Responsibility  for  managing  this 
communal  repository  would  rest  in  an  authoritative  body  that  would  determine  knowledge  to  be 
included,  formalize  its  representation,  index  it  for  retrieval,  and  keep  it  updated.  Projects  initiated  over 
the  past  two  years  have  begun  to  tackle  this  idea. 

In  2008  AHRQ  issued  contracts  for  two  projects,  the  Guidelines  into  Decision  Support  (GLIDES)  project 
and  a  Clinical  Decision  Support  Consortium  (CDSC).  The  GLIDES  project  is  concerned  with  the 
lifecycle  of  transforming  guidelines  from  narrative  form  to  implementation.  The  CDSC  aims  to  develop 
cooperative  approaches  to  share  and  manage  CDS  knowledge.  The  CDSC,  which  includes  health  care 
organizations  and  vendors,  is  using  a  top-down  approach  to  develop  knowledge  management  models, 
representations,  and  lifecycle  processes,  based  on  the  internal  knowledge  management  portal 
development  at  Partners  Healthcare,  and  a  proprietary  content  management  platform  (Documentum, 
EMC  Corp.,  Hopkinton,  MA). 

The  Morningside  Initiative,  described  in  this  paper,  arose  at  about  the  same  time  as  the  above  efforts,  in 
2006-2007,  as  a  consortium  committed  to  developing  an  open,  collaborative  process  for  knowledge 
management  in  order  to  create  a  shared  repository  of  content  for  CDS  that  would  be  as  close  to 
implementable  form  as  possible.  Further,  a  goal  of  this  group  was  to  follow  best  available  models  for 
knowledge  representation  and  to  help  drive  the  standards  development  process  where  appropriate 
standards  were  lacking. 

A.2  The  Morningside  Initiative 

The  Morningside  Initiative  began  when  a  small  group  of  prominent  health  care  organizations  came 
together  for  a  working  meeting  at  the  Morningside  Inn,  Frederick,  MD,  August  28-30,  2007,  under  the 
sponsorship  of  the  Telemedicine  and  Advanced  Technologies  Research  Center  (TATRC)  of  the  US  Army 
Medical  Research  and  Materiel  Command.  The  purpose  was  to  develop  a  long-term  plan  intended  to 
address  the  challenges  by  means  of  a  deliberate,  gradual  process,  initially  involving  selected  participants 
for  a  limited  set  of  tasks,  and  then  expanding  in  scope  and  scale  as  workable  approaches  are  developed. 
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Participants  included  representatives  of  the  Department  of  Defense  (DoD)  Tri-Care  Management/Health 
Affairs  (TMA/HA),  the  Veterans’  Health  Administration  (VHA),  Partners  Healthcare  System  (Partners), 
Kaiser  Permanente  (Kaiser),  Henry  Ford  Health  System  (HFHS),  Arizona  State  University  (ASU),  the 
AMIA,  and  TATRC. 

The  Morningside  Initiative  is  the  result  of  that  August  2007  initial  working  meeting,  and  was  the 
unanimous  recommendation  of  participants.  It  called  for  a  collaboration  to  create  a  repository  of  shared 
knowledge  for  CDS  to  meet  the  needs  of  and  be  made  available  to  diverse  healthcare  providers  and 
organizations.  Subsequent  to  the  initial  meeting,  Intermountain  Healthcare  (Intermountain)  joined  the 
other  participants  to  form  the  Morningside  Initiative. 

A.3  Morningside  Initiative  Vision 

The  Morningside  Initiative  is  dedicated  to  developing  a  collaborative  Web-based  resource  that  supports 
the  sharing  of  evidence-based  medical  knowledge  in  executable  form  for  clinical  decision  support,  in 
order  to  improve  the  health  of  the  community  and  the  quality  of  health  care, _ 

To  achieve  this  vision,  the  collaboration  is  a  prototype  of  a  larger  future  knowledge-sharing  organization, 
aiming  at  developing  and  refining  (1)  an  organizational  framework,  (2)  a  technical  approach,  and  (3) 
content  acquisition  and  management  processes  that  are  functional  and  can  be  scaled  up  to  include  a 
broader  range  of  participants  as  well  as  an  expansion  of  capabilities  and  content  scope.  The  organizers 
of  the  Morningside  Initiative  concluded  that  the  challenges  of  knowledge  sharing  (access  to  high  quality 
content,  reusability,  tools  for  knowledge  management,  and  an  organizational  framework  to  facilitate 
knowledge  exchange)  would  best  be  addressed  by  bringing  together  its  small  number  of  highly  visible 
and  respected  health  care  organizations  in  the  public  and  private  sector  that  could  lead  by  example. 

They  would  develop  and  test  a  framework  for  knowledge  sharing  that  could  be  extended  to  a  national- 
level  effort  if  successful.  The  rationale  for  this  approach  was  based  on  three  primary  considerations: 

(a)  Working  out  the  organizational  and  logistical  issues  of  knowledge  sharing  could  be  best  done  first 
with  a  small  number  of  participants,  so  that  the  approaches  can  be  refined  through  that  experience, 
before  undertaking  a  large-scale  initiative  involving  many  more  participants. 

(b)  Reluctance  to  share  clinical  knowledge  by  institutions  could  be  overcome  if  high-profile  participants 
have  already  committed  to  doing  so  and  seeded  the  effort  with  a  corpus  of  useful  knowledge  content. 

(c)  Tools  and  methods  for  knowledge  management,  for  creating,  representing,  and  updating  the  content, 
and  for  facilitating  adaptation  and  reuse  in  other  sites  should  be  developed  and  piloted  with  this  small 
group. 

The  general  framework  for  the  Morningside  Initiative  is  shown  in  Fig.  1.  Current  efforts  are  to  capture 
best  available  knowledge  already  implemented  as  CDS  in  the  systems  of  participant  organizations; 
represent  it  in  a  more  sharable,  less  setting-dependent  format;  drive  toward  standards-based  models 
for  representation;  and  develop  and  test  approaches  for  secondary  reuse.  The  key  test  of  reuse  is  the 
adoption  of  this  knowledge  in  settings  different  from  those  from  which  the  CDS  had  originally  been 
implemented. 

In  the  future,  it  is  anticipated  that  external  knowledge  will  continually  arise  from  authoritative  studies, 
and  that  a  process  will  be  established  to  regularly  incorporate  this  knowledge  into  the  shared 
knowledge  base.  This  is  discussed  further  in  the  section  on  Future  Directions. 

The  rationale  for  the  effort  included  the  following  potential  benefits: 

•  In  concert  with  the  nationwide  efforts  to  achieve  widespread  adoption  of  interoperable  health  IT,  a  col¬ 
laborative  approach  will  help  attain  greater  proliferation  of  CDS  than  any  one  entity  could  achieve 
alone. 
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•  Consistent  with  views  at  the  time  of  formation,  and  in  concert  with  the  2008  Department  of  Health  and 
Human  Services  (DHHS)  goal  of  “privatizing”  AHIC  by  forming  public-private  entities,  this  effort  will 
help  to  achieve  the  Secretary’s  HIT  goals  of  an  interoperable  and  transparent  process. 

•  The  approach  will  broaden  the  potential  use  and  application  of  CDS  at  the  point  of  care  in  order  to 
impact  health  care  decisions  throughout  the  health  care  system. 

•  It  will  extend  the  reach/resources  of  participating  entities  beyond  those  possible  when  working  alone. 

•  It  will  advance  and  foster  more  widespread  accessibility  of  CDS  content  and  interventions. 

•  By  leveraging  lessons,  tactics  and  approaches  used  by  others,  buy-in  across  local,  regional  and  na¬ 
tional  entities  will  be  increased. 

•  A  collective  effort  will  address  CDS  topics  of  prime  concern  and  importance  to  the  national  health 
care  system  in  terms  of  cost,  quality,  and  access  to  care. 

•  A  national-level  resource  will  facilitate  adoption  and  more  effective  use  of  CDS  within  organizations 
that  might  otherwise  not  have  the  resources  to  pursue  CDS. 

•  Collaboration  and  sharing  CDS  mechanisms  will  help  leverage  prior,  current  and  ongoing  work;  and 
will  help  individual  organizations  and  entities  capitalize  on  lessons  learned  and  approaches/methods 
that  have  been  successful,  thereby  avoiding  the  need  to  reinvent  the  wheel. 

•  Availability  of  the  resource  will  remove  or  lessen  barriers  and  challenges  (in  terms  of  technical,  cost, 
and  expertise  deficiencies)  and  thus  enhance  the  likelihood  of  adoption  and  proliferation  of  CDS. 

•  Professional  benefits  will  accrue  to  individual  investigators  for  participation  (e.g.,  papers,  grant  writing, 
research,  and  leadership  opportunities). 

•  The  collaborative  mechanism  will  provide  participating  entities  with  a  level  of  external  validation  of 
their  CDS  work  regarding  content  quality  and  development  approach. 

•  The  approach  will  promote  best  practices  for  developing  CDS  interventions  among  and  across  enti¬ 
ties  and  organizations. 

A  recognized  requirement  for  a  future  collaborative  knowledge  sharing  organization  is  a  business  model 
based  on  sustainable  long-term  mechanisms  of  support,  yet  to  be  defined,  which  might  be  expected  to 
include  a  combination  of  organizational  subsidies  or  membership  dues,  governmental  and  insurance 
industry  funding,  and  possibly  other  mechanisms.  For  the  short  term,  limited  support  has  been  provided 
through  TATRC,  and  additional  sources  of  support  are  being  sought.  Most  of  the  activities  described  in 
this  report  have  been  carried  out  through  the  in-kind  contributions  of  time  and  effort  by  the  participants 
and  their  organizations. 

A.4  Morninqside  Initiative  Scope 

The  initiative  described  here  does  not  duplicate  the  work  of  Evidence-based  Practice  Centers,  the 
Cochrane  Collaboration,  Comparative  Effectiveness  Research,  or  other  efforts  to  determine  best 
practices  and  to  develop  guidelines  based  on  meta-analysis  and  evidence-based  medicine.  An 
operational  knowledge  repository  would,  however,  regularly  draw  upon  the  work  of  these  organizations  to 
operationalize  their  findings.  For  the  near  term,  the  Morningside  Initiative  takes  as  its  starting  point  the 
"operationalized”  knowledge  that  health  care  provider  organizations  have  already  determined  to  be  useful 
and  have  implemented  in  various  applications  in  their  systems,  usually  in  the  form  of  decision  rules  for 
alerts,  reminders,  or  medication  prescribing  recommendations,  or  as  order  sets.  Typically  these  CDS 
modules  have  been  drawn  from  guidelines,  authoritative  reviews  or  other  evidence-based  medicine 
sources,  but  they  have  been  made  unambiguous  and  computable  -  a  process  which  sounds 
straightforward  but  is  definitely  not.  Further,  typically  these  modules  are  not  represented  in  a  language 
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that  can  be  interpreted  by  other  systems  or  applications,  even  within  the  same  organization.  So  a  major 
focus  is  to  develop  a  common  shared  representation  for  such  knowledge. 

A  subsequent  phase  of  the  Morningside  Initiative  is  anticipated,  which  includes  a  national-scale  effort  to 
maintain  and  update  a  shared  repository  of  executable  knowledge.  This  would  include  a  regular  process 
to  review  and  incorporate  new  knowledge  coming  from  such  authoritative  sources  as  above.  However, 
that  is  not  the  initial  focus  of  the  effort. 

A. 5  The  importance  of  sharing,  standards,  and  open  systems 

The  ultimate  purpose  of  this  effort  is  to  establish  a  continually  updated  and  widely  accessible  national- 
level  repository  of  authoritative  knowledge  in  executable  form.  The  details  of  the  knowledge  are  to  be 
fully  transparent.  That  participation  will  be  available  to  all  is  a  guiding  principle.  Participation  fees,  if  any, 
will  not  be  a  barrier,  but  may  be  required  for  self-sustaining  operation. 

Since  standards  are  still  immature,  the  goal  of  being  able  to  provide  knowledge  in  standard  form  is  not 
fully  attainable.  Nonetheless,  the  Morningside  Initiative  intends  to  represent  knowledge  in  unambiguous 
form  by  using  (or  developing  as  needed)  conventions  for  representation  that  are  considered  by  the  team 
to  be  the  best  available,  and  which  are  fully  documented.  The  team  also  works  with  standards 
development  organizations  to  help  accelerate  the  adoption  of  standards  that  are  most  urgently  needed. 

It  is  expected  that  as  this  effort  gains  traction  it  may  provide  a  major  use  case  for  such  standards 
development,  to  help  drive  the  direction  of  the  process. 

A  principle  of  the  approach  is  that  knowledge  bases  are  managed  using  open  source  tools  and  non¬ 
proprietary  data  formats  wherever  possible.  This  avoids  licensing  fees  or  vendor  dependence,  or  the 
delays  in  waiting  for  vendors  to  support  particular  needed  features.  Open  platforms,  e.g.,  the  J2EE 
framework,  have  demonstrated  scalability  and  performance,  and  there  are  growing  numbers  of  open- 
source  software  products  available  for  various  needs. 

B.  METHODS 

The  Morningside  Initiative  takes  a  lifecycle  approach  to  establishing  the  needed  organization, 
infrastructure,  and  expertise  to  operate  such  an  ongoing  activity  for  CDS  sharing  and  reuse.  The 
lifecycle  includes: 

(a)  content  knowledge  acquisition  (review,  vetting) 

(b)  knowledge  representation  (formalization,  standardization,  and  separation  of  core  medical 
knowledge  from  contextualization/business  process  aspects), 

(c)  knowledge  management  (curation  and  update),  and 

(d)  knowledge  adoption  (adaptation  and  deployment  in  operational  settings). 

The  process  is  driven  ultimately  by  the  functional  requirements  for  (d)  adoption,  since  putting  the 
knowledge  to  use  is  the  motivation  for  the  whole  effort.  Ideals  are  that  the  knowledge  be  of  high  quality, 
vetted,  executable,  and  interoperable  in  a  clinical  setting.  Each  of  these  characteristics  is  important.  To 
be  regarded  as  high  quality,  it  needs  to  have  a  means  for  viewing  its  evidence  base,  the  authors  and 
their  credentials,  and  experience  with  it.  To  be  vetted  implies  that  there  is  an  identifiable  review  process 
that  has  certified  CDS  quality  and  suitability  for  implementation.  To  be  executable  implies  that  it  has 
been  formalized  to  a  point  that  eliminates  ambiguity  and  that  the  data  sources  on  which  it  depends  are 
obtainable.  To  be  interoperable  implies  that  the  definition  is  platform-independent.  Adoption  in  a 
clinical  setting  implies  that  it  can  be  adapted  appropriately  to  the  site’s  specific  health  information 
system,  operations,  and  workflow  characteristics. 

The  Morningside  Initiative  is  governed  by  a  Steering/Organization  Committee  overseeing  two  other 
Committees  functioning  as  Working  Groups.  The  committee  responsibilities  are  as  follows: 
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•  Steering/Organization  Committee  -  Initially  composed  of  representatives  of  all  founding  organiza¬ 
tions,  the  Steering  Committee  is  expected  to  evolve  into  elected  membership  based  on  constituen¬ 
cies,  such  as  professional  specialty  societies,  health  care  delivery  organizations,  knowledge  content 
provider  entities  (commercial  and  otherwise),  and  other  stakeholders  to  be  defined.  This  committee 
oversees  the  development  and  refinement  of  the  bylaws  operating  procedures,  conducts  govern¬ 
ance  business,  and  oversees  the  evaluation  and  sustainability  aspects  of  the  Initiative. 

•  Content  Committee  -  This  Committee  is  responsible  for  specifying  content  focus  priorities,  acquisi¬ 
tion,  review,  and  rating  procedures,  and  overseeing  the  content  update  to  the  repository. 

•  Tools  and  Methods  Committee  -  This  committee  is  responsible  for  functional  requirements,  tools 
specification,  development  and  testing,  and  deployment/technical  operations.  It  is  also  the  primary 
interface  for  engagement  with  the  standards  development  process  through  participation  in  HL7, 
OASIS,  and  other  SDOs. 

The  Morningside  Initiative  is  working  in  collaboration  with  the  Congressionally-funded  Knowledge 
Management  Repository  (KMR)  project,  directed  by  CAP  Emory  Fry,  MD,  at  Naval  Health  Research 
Center,  San  Diego,  CA,  .  The  KMR  project  is  aimed  at  developing  an  open-source  platform  for  CDS  for 
the  Federal  NHIN-CONNECT  implementation.  Thanks  to  this  collaboration  and  a  cooperative  research 
and  development  agreement  (CRADA),  this  hardware/software  stack  is  installed  at  the  ASU  CARE-IT 
Laboratory  (http://care-it.asu.edu).  and  is  available  for  Morningside  Initiative  work.  CARE-IT  is 
collaboration  between  academic,  government  and  industrial  partners  established  to  promote  research 
into  open-source,  interoperable  and  standards-based  solutions  for  health  care  information  technology 
(HIT)  and  to  provide  an  innovative  infrastructure  for  the  education  of  health  care  and  technology 
professionals.  We  use  this  resource  as  the  technical  framework  for  hosting  the  CDS  knowledge 
repository,  delivering  and  ensuring  interoperability  of  the  components  of  this  research  -  both  the 
content  repository,  tools,  and  resources  needed  for  their  support  -  and  providing  a  collaboration 
environment  for  participants. 

The  Morningside  Initiative  has  adopted  a  management  strategy  that  we  believe  to  be  truly  inclusive  and 
collaborative.  The  above  committees,  when  they  identify  a  task  to  be  performed,  designate  a  commit¬ 
tee  liaison  person  (either  on  the  committee  or  approved  by  the  committee  membership)  as  the  one  re¬ 
sponsible  for  overseeing  that  task.  Together  with  the  committees,  the  scope  of  the  project,  resource 
requirements,  priority,  and  timeline  are  determined,  and  if  approved  by  the  committee,  the  resources 
are  allocated  from  the  technical  team.  The  coordination  of  requests  is  overseen  by  a  Project  Manage¬ 
ment  Team  of  the  Steering/Organization  Committee. 

Specific  activities  include  the  following: 

B.l.  Establish  open  source,  standards-based,  shared  repository 

The  functional  requirements  for  delivery  define  needs  for  the  CDS,  the  process  for  selecting  and 
rating  the  CDS  for  inclusion  in  the  repository,  the  tools  and  methods  for  representing  it,  and  approaches 
for  contextualizing  it  for  use.  Ideally,  we  further  impose  that  the  content  and  tools  be  standards-based 
and  open  source,  and  that  the  processes  involved  in  implementing  the  life  cycle  be  that  of  an  active, 
engaged,  viral  open  source  community  of  knowledgeable  developers  and  users.  A  draft  set  of 
functional  requirements  (see  Table  1)  forms  a  basis  for  our  approach  and  is  being  further  refined. 

The  initial  focus  in  the  Morningside  Initiative  has  been  on  CDS  content  which  is  already  implemented  in 
existing  participant  sites  and  which  has  been  shown  to  be  effective.  The  aim  is  to  learn  from  examining 
that  content  what  the  unique  features  of  each  implementation  are,  to  compare  knowledge  aimed  at 
similar  purposes,  and  to  forge  a  common  representation.  Knowledge  content  foci  are  determined  by 
the  organization/steering  committee,  and  are  initially  primarily  aimed  at  high  priority  clinical  conditions, 
notably  involving  chronic  disease.  We  have  further  restricted  our  activities  thus  far  to  examination  of 
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diabetes  rules-based  knowledge,  e.g.,  HbAlc  testing,  Metformin  prescribing,  eye  and  foot  examination 
reminders,  and  operational  definitions  of  chronic  diseases. 

Once  having  created  a  sharable  representation,  abstracting  context-specific  and  site-specific  aspects, 
the  goal  is  to  re-contextualize  the  content  to  enable  it  to  be  incorporated  into  another  site  with  distinct 
EHR  platform,  organization,  and  workflow  requirements.  This  analysis  of  content  has  to  date  been  very 
instructive,  and  has  identified  the  need  to  separate  the  core  medical  knowledge  from  the  business  or 
workflow  logic  and  to  characterize  a  variety  of  annotation  meta-tags  (see  Table  2)  that  relate  to  things 
like  how  the  CDS  is  triggered,  how  and  where  it  interacts  with  applications  and  users  during  evaluation, 
and  how  the  results  are  communicated  or  inserted  into  the  workflow. 

We  have  also  shown  that  many  apparently  different  rules  are  for  the  same  medical  purpose,  once  one 
does  the  above  analysis.  This  is  exemplified  in  Fig.  2,  which  is  a  spreadsheet  comparing  knowledge 
content  gathered  from  Morningside  Initiative  participant  implementations  dealing  with  various  diabetes- 
related  rules.  For  example,  a  variety  of  different  rules  are  seen  all  dealing  with  how  to  deliver  a 
reminder  that  HgbAlc  testing  should  occur  every  6  months.  It  is  clear  that  the  differences  in 
appearance  are  all  due  to  the  triggering,  presentation,  and  other  business  logic  considerations.  Thus  a 
major  task  of  this  initiative  is  to  formalize  the  content  acquisition  process  in  order  to  understand  how  to 
represent  these  layers. 

B.2.  Develop  robust  content  knowledge  management  practices  and  technical  resources  and 
procedures,  methodologies,  and  representations  of  knowledge 

The  key  innovation  in  the  technical  approach  is  to  put  together  a  variety  of  emerging  open  source 
capabilities  and  to  engage  the  community  in  an  active  collaborative  mode  in  its  development,  testing, 
and  refinement. 

Functional  requirements  development.  The  evolving  set  of  functional  requirements  for  the 
Morningside  Initiative  has  been  prepared  together  with  those  being  developed  for  the  KMR  project.  The 
latter  are  aimed  more  at  the  end-user  delivery  phase  of  CDS,  but  we  believe  that  the  requirements  for 
the  knowledge  model  and  representations  cannot  be  divorced  from  the  functional  requirements  for  the 
delivery  of  CDS,  and  thus  we  are  evolving  these  together.  As  noted  above,  see  Table  1  for  draft 
Morningside  Initiative  requirements. 

As  mentioned  above,  the  focus  of  the  Morningside  Initiative  effort  has  not  been  to  develop  new 
knowledge.  Nor  has  it  been  to  render  poorly  specified,  existing  logic  as  explicit,  computable  rules. 
Instead,  our  focus  has  been  on  a  model  and  mechanism  for  capturing  computable,  clinical  knowledge  in 
a  Knowledge  Repository  (KR)  and  for  making  that  knowledge  available  to  systems  with  the 
infrastructure  necessary  to  deliver  CDS  interventions  in  a  way  that  can  improve  local  care  delivery.  To 
accomplish  this,  the  Morningside  Initiative  has  focused  on  existing  medical  knowledge,  already  in  use  in 
the  collaborating,  Morningside  Initiative  sites.  This  CDS  logic  provides  examples  of  content  around 
which  we  build  the  KR  and  define  its  methodological  requirements. 

Using  tested  content  as  a  starting  point,  we  can  address  two  of  the  key  needs  surrounding  the  transfer 
of  CDS  between  sites:  (1 )  detailed  documentation  of  the  functional  requirements  for  each  of  the 
components  found  in  an  environment  that  supports  CDS,  and  (2)  a  collection  of  use  cases  from  which 
we  can  catalog  characteristics  of  the  clinical  workflow  and  the  clinical  environments  necessary  for  the 
successful  delivery  of  CDS. 

This  functional  requirements  draft  document  indicates  anticipated  capabilities  of  a  knowledge 
repository,  of  a  knowledge  authoring  and  maintenance  system,  of  a  service  to  support  the  sharing  of 
this  knowledge,  and  finally,  of  a  typical  system  for  executing  logic  imported  through  this  service.  Since 
these  functional  requirements  are  derived  from  the  experience  of  multiple  institutions,  no  specific 
language  or  implementation  is  described.  The  goal  of  the  requirements  document  is  to  be  complete,  to 
the  extent  that  a  system  developer  might  choose  to  implement  a  subset  of  the  described  functions  and 
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have  a  usable  system.  However,  this  detailed  level  of  specification  is  appropriate  for  a  knowledge 
repository,  since  such  a  repository  would  be  expected  to  manage  logic  from  sites  that  have 
implemented  differing  subsets  of  the  defined  functionality. 

The  document  referred  to  is  in  its  first  draft.  An  important  activity  in  the  next  several  months  will  be  to 
further  extend  and  define  these  CDS  functional  requirements.  The  result  will  be  a  catalog  of  the 
functions  that  would  necessarily  need  to  be  supported  in  a  repository  for  shareable  medical  knowledge. 
The  functional  requirements  will  eventually  also  expand  in  scope  to  include  those  requirements  relating 
to  new  content  knowledge  acquisition  and  authoritative  review/rating. 

The  second  component  of  this  analysis  involves  an  aspect  of  CDS  that  clearly  requires  more  study. 
Medical  decision  modules  can  be  integrated  into  a  clinical  workflow  in  a  variety  of  different  ways. 

Similar  logic  could  support  alerts,  observations  displayed  in  clinical  worksheets,  suggested  orders  in  a 
CPOE  system,  and  a  number  of  other  potential  delivery  mechanisms.  We  believe  that  this  attention  to 
clinical  work  processes  is  essential  for  successful  implementation  of  CDS.  A  knowledge  repository  that 
fails  to  document  the  approach,  timing,  and  context  of  the  delivery  of  a  CDS  intervention  would  leave  a 
site  that  wishes  to  import  these  rules  with  documentation  inadequate  to  do  so  successfully. 

As  we  proceed  in  this  work,  we  anticipate  evaluating  CDS  logic  from  a  number  of  institutions.  We  will 
treat  these  as  "use  cases"  from  which  we  will  document  the  characteristics  of  the  work  processes  that 
are  used  in  successful  CDS  implementations.  We  anticipate  developing  or  adopting  templates  and 
terminologies  appropriate  to  capturing  this  information.  This  documentation  will  make  the  character  and 
implications  of  the  chosen  intervention  clear  to  any  manager  of  a  decision  support  environment  who 
attempts  to  implement  logic  imported  from  the  KR. 

Tools  and  architectural  approaches  based  on  KMR  project.  The  KMR  project  has  developed  an 
NHIN-compatible  set  of  interoperable  components  that  the  Morningside  Initiative  can  build  upon  for  its 
work.  The  KMR  focus  has  been  to  demonstrate  that  CDS  material  can  be  retrieved  from  a  shared 
repository  and  executed  within  both  military  and  civilian  health  information  systems.  It  seeks  to  create 
an  open  source  infrastructure,  based  on  the  FHA  NHIN-Connect  open  source  release,  for  sharing 
domain  knowledge  and  executing  CDS.  The  uniqueness  of  this  approach  is  that  it  will  not  only  result  in 
an  open  standards  platform  with  standardized  application  program  interfaces  (APIs)  and  services,  but  it 
will  also  contribute  to  the  growth  of  a  collaborative  academic  community,  dedicated  to  improving 
healthcare.  To  support  ongoing,  iterative  improvement  in  functional  and  technical  capabilities,  the 
system  is  being  designed  to  collect  performance  and  usability  metrics. 

Thus  the  KMR  project  is  being  treated  by  the  Morningside  Initiative  as  a  key  use  case  for  delivery  that 
has  a  shared  design  approach  -  that  of  an  interoperable,  standards-based,  open  source  set  of  tools 
and  resources,  and  an  active,  engaged  community  of  developers  and  users. 

Additional  tools,  methods,  and  processes.  As  part  of  its  ongoing  work,  the  Morningside  Initiative 
seeks  to  adapt  from  the  above,  obtain  externally,  or  build  other  tools  and  processes  to  construct, 
maintain  and  use  CDS  knowledge  in  a  KR. 

Several  aspects  of  the  KR  environment  deserve  mention.  First,  the  long-term  goal  is  to  conveniently 
host  knowledge  for  thousands  of  decision  modules  over  long  time  periods.  This  implies  that  there  must 
be  good  tools  for  searching  for  decision  modules,  versioning  decision  modules,  importing  and  exporting 
decision  modules,  testing  decision  modules,  etc.  In  addition,  the  repository  needs  to  contain  more  than 
just  the  decision  logic.  We  have  begun  to  assemble  a  list  of  metadata  (see  Appendix  B)  that  we 
anticipate  will  be  necessary  for  the  management  of  this  decision  logic  as  well  as  to  support  queries  from 
users  of  this  system  searching  for  logic  to  import  into  their  own  clinical  information  systems. 

Additional  components  of  the  knowledge  repository  will  include  several  forms  of  knowledge 
documentation.  Users  searching  for  CDS  logic  to  implement  in  their  local  medical  environment  will  wish 
to  review  experience  with  specific  collections  of  knowledge  before  they  import  and  implement  this  logic. 
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We  anticipate  providing  for  storage  and  retrieval  of  both  unstructured  and  structured  documentation. 
Pointers  to  appropriate  articles  and  other  documents  will  be  provided,  as  would  forms  that  allow  a 
knowledge  depositor  to  record  measures  of  the  success  of  the  logic  within  the  submitting  institution.  A 
user  making  a  knowledge  withdrawal  would  have  access  to  this  information  to  help  predict  the 
effectiveness  of  these  CDS  modules  in  his/her  institution.  We  expect  to  use  Web  2.0  rating  and 
commenting  methods  for  enriching  the  knowledge  in  the  repository  with  user  experience  and 
observations. 

These  and  other  functions  of  the  KR  will  be  mediated  by  tools  and  processes  to  support: 

•  Knowledge  Repository:  The  KR  will  consist  of  an  appropriate  database  of  medical  logic  and  sup¬ 
porting  information  combined  with  a  collection  of  services  to  mediate  interactions  with  the  database 
including  knowledge  import,  knowledge  export,  multidimensional  search,  and  other  interactions  with 
the  stored  medical  logic  and  supporting  information. 

•  Knowledge  Authoring:  A  knowledge  authoring  and  editing  environment  for  importing  of  existent 
CDS  content  from  collaborating  institutions,  inspecting  and  editing  content,  and  entering  and  editing 
the  metadata  used  to  support,  explain,  and  identify  repository  knowledge. 

•  Knowledge  Management:  As  knowledge  is  edited,  superseded,  or  expanded  through  additional 
cycles  of  importation  and  editing,  facilities  for  supporting  these  activities  and  for  versioning  and  an¬ 
notating  the  evolving  CDS  logic  will  be  needed.  These  will  be  provided  along  with  the  essential 
search  tools  to  explore  the  stored  CDS  logic,  its  metadata,  and  its  documentation. 

•  Knowledge  Testing:  A  function  previously  used  by  some  of  the  collaborating  institutions  is  the  abil¬ 
ity  to  test  knowledge  using  a  collection  of  data  (de-identified  or  simulated).  This  has  proven  valu¬ 
able  as  CDS  logic  is  edited  and  versioned.  As  a  part  of  this  work,  we  will  explore  the  appropriate 
way  to  capture  and  manage  test  data  within  the  knowledge  repository  and  will  provide  tools  so  that 
regression  testing  of  clinical  logic  can  be  accomplished. 

•  Knowledge  Documentation:  Tools  will  be  provided  to  support  and  enhance  the  documentation  of 
CDS  knowledge  stored  in  the  knowledge  repository.  These  will  include  import  functions  for  various 
documents  such  as  articles  and  user  guides  as  well  as  forms  designed  to  capture  various  character¬ 
istics  of  the  imported  logic.  These  characteristics  would  include  measured  response  rates  for  alerts, 
descriptions  of  user  interfaces,  metadata  capturing  the  character  of  the  implemented  workflow,  etc. 

The  tools  above  are  specific  to  the  day-to-day  use  of  the  knowledge  repository.  However,  we  anticipate 
implementing  a  collection  of  applications  and  extensions  to  user  tools  to  monitor  usage  of  the 
knowledge  repository.  As  a  part  of  our  efforts  to  provide  short-  and  long-term  information  with  which  to 
evaluate  the  success  of  this  KR  design,  we  will  implement  a  variety  of  audit  trails  and  logs  capturing  the 
usage  of  this  standards-based,  open  source,  knowledge  repository. 

Examples  of  open  source  tools  and  platforms  that  we  intend  to  explore  are  (a)  the  NHIN-Connect  tools, 
(b)  the  BioCore  collaboration  portal  being  fielded  at  ASU,  built  on  a  .NET  framework  and  supporting 
workspaces  for  collaboration;  (c)  content  management  environments  such  as  Alfresco  (open-access 
derivative  of  Documentum);  and  (d)  Drools,  a  rules  engine  system. 

B.3.  Establish  an  operational  public-private  consortium 

The  organization  of  the  Morningside  Initiative  will  be  subject  to  a  set  of  procedures  set  forth  in  a  Bylaws 
document.  The  Morningside  Initiative  is  a  public-private  collaboration  organized  under  a  memorandum 
of  understanding  (MOU)  signed  by  all  participants.  The  Morningside  Initiative  and  AMIA  have  agreed  in 
principle  for  the  Morningside  Initiative  to  be  affiliated  under  AMIA  as  an  intermediate  means  to  formalize 
the  entity  and  carry  out  the  business  on  behalf  of  its  constituency.  This  was  done  as  a  way  to  maximize 
flexibility  for  long-term  operation  and  sustainability  as  the  entity  expands  to  be  a  fully  inclusive  national- 
scale  initiative.  Other  organizational  and/or  governance  structures  or  approaches  may  be  considered  in 
the  future. 


Draft  bylaws  and  the  proposed  AMIA  affiliation  agreement  are  currently  being  reviewed.  Bylaws  include 
language  that  addresses  indemnification  and  intellectual  property  protection.  Participants  sharing 
content  will  need  to  be  indemnified  by  clinical  care  organizations  accessing  and  implementing  this 
content  in  their  respective  clinical  decision  support  systems.  Further,  those  sharing  content  will 
be  responsible  for  respecting  their  own  third-party  content  intellectual  property  agreements  as  well 
as  protected  from  having  their  shared  artifacts  sold  by  other  third  parties. 

The  original  intent  in  forming  the  Morningside  Initiative  was  to  limit  participants  initially,  until  the 
organization,  content,  and  technical  approaches  were  sufficiently  defined,  before  expanding.  We  have 
learned  much  in  the  past  year  about  the  nature  of  the  collaboration  process,  however,  and  that  it  may 
be  possible  to  actually  move  more  quickly  to  a  broader  scale,  by  fully  embracing  an  open  source,  open 
collaboration  model.  A  key  reason  for  this  is  that  we  have  found  that  the  interest  in  this  activity  is  much 
broader  than  we  had  originally  believed,  given  the  general  reluctance  to  sharing  of  CDS  over  the  past 
decade.  A  large  part  of  this  is  due  to  the  focus  of  ONC,  AMIA,  and  various  leading  health  care 
organizations  on  CDS,  the  priorities  of  the  Obama  administration,  and  the  new  vibrancy  of  open  source 
communities  in  production  environments,  notably  in  health  care. 

B.4.  Drive  standards  evolution  and  adoption 

A  long-term  goal  of  the  process  described  above  is  to  create  a  resource  that  will  become  increasingly 
used  and  valued  as  more  and  more  of  the  management  and  documentation  of  health  care  in  the  U.S.  is 
carried  out  electronically.  We  are  convinced  that  development  of  and  adherence  to  standards  are 
central  to  effective  implementation  of  EHRs  and  CDS.  We  are  committed  to  using  existing  standards  in 
this  knowledge  repository  and,  where  standards  are  insufficient  or  do  not  exist,  we  anticipate  applying 
the  lessons  learned  in  the  analysis  and  design  of  the  repository  to  promote  extension  of  standards  or  to 
create  new  standards  as  needed. 

Two  kinds  of  standards  are  particularly  applicable  for  those  who  wish  to  share  CDS  knowledge.  The 
first  is  the  language  in  which  this  knowledge  is  expressed.  In  the  realm  of  medicine,  two,  overlapping, 
HL7  standards  exist.  These  are  the  Arden  Syntax  for  medical  logic  modules  [16]  and  the  GELLO 
expression  language  [18].  However,  neither  of  these  has  seen  widespread  adoption  in  the  medical 
computing  community,  except  in  the  case  of  Arden  Syntax,  within  vendor-specific  implementations.  An 
interesting  alternative  to  these  standards  is  represented  by  the  growing  use  of  business  rules  engines 
and  other,  general-purpose  decision  tools  in  some  clinical  environments.  It  appears  that  a  repository 
that  supports  a  single,  computable  representation  of  CDS  logic  will  not  be  adequate. 

In  this  context,  the  Morningside  Initiative  has  begun  to  explore  the  possibility  of  an  XML-based 
Interlingua  as  a  possible  tool  for  translating  among  different  logic  representations.  Examples  of  such 
tools  include  the  W3C  RuleML  (http://ruleml.orq/)  and  a  version  of  the  Arden  Syntax  expressed  fully  in 
XML  [1 9].  One  of  the  goals  of  this  effort  will  be  to  evaluate  a  subset  of  the  existing  (medical  and 
nonmedical)  standards  to  determine  if  the  development  of  a  medical  rules  interchange  format  is 
possible.  The  key  goal  of  such  an  interchange  format  would  be  to  support  translations  of  CDS  logic 
between  languages. 

In  this  activity  we  anticipate  leveraging  the  work  of  others.  The  Morningside  Initiative  and  KMR 
collaborators  have  regular  interactions  with  a  variety  of  standards  organizations  and  expect  to  promote 
the  adoption  or  development  of  a  medical  rules  interchange  format  if  further  analysis  confirms  the 
feasibility  of  this  approach. 

The  second  kind  of  standard  that  is  essential  to  the  sharing  of  CDS  logic  is  a  mechanism  to  readily 
adapt  decision  logic  built  using  data  of  one  institution  for  use  with  data  queried  from  the  clinical 
database  of  a  second  institution.  The  central  challenge  when  importing  medical  logic  into  a  new  clinical 
setting  is  to  bind  this  logic  to  local  data  models  and  terminologies.  This  problem  is  known  generically 
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as  the  "curly  braces"  problem,  arguably  a  key  reason  for  the  limited  dissemination  of  the  Arden  Syntax 
as  a  mechanism  for  exchanging  medical  knowledge. 

The  Morningside  Initiative  plans  to  approach  this  challenge  through  analysis  of  two  evolving  standards. 
One  of  these,  the  virtual  medical  record  (vMR)  offers  the  option  of  mapping  a  nonstandard  data 
representation  onto  a  simplified  version  of  the  HL7,  version  3,  data  messaging  standard.  The  other,  a 
product  of  the  Healthcare  Services  Specification  Project  (HSSP),  standardizes  CDS  as  a  service.  The 
mapping  of  local  data  to  the  symbolic  forms  used  in  the  CDS  logic  occurs  during  the  construction  of  the 
message  used  to  invoke  the  service. 

We  believe  that  a  key  product  of  our  future  work  will  be  examples,  use  cases,  and  functional 
requirements  designed  to  support  the  implementation  of  decision  logic,  imported  from  the  repository,  in 
settings  where  data  models  and  terminologies  differ  from  those  present  in  the  originating  site. 

B.5.  Demonstrate  suitability  and  value  for  secondary  reuse 

We  are  exploring  this  concept  in  two  ways.  One  is  adaptation  to  local  processes/workflows,  and  the 
other  is  adaptation  to  local  data  representations.  In  these  activities,  we  seek  to  use  standards  wherever 
adequate.  We  intend  to  demonstrate  the  ability  to  technically  interface  the  CDS  into  different  platforms. 
One  target  is  the  DOD  AHLTA  system  being  explored  through  the  KMR  project.  Another,  to  be  done 
between  KMR  and  the  ASU  CARE-IT  lab,  is  the  Resource  and  Patient  Management  System  (RPMS)  of 
the  Indian  Health  Service.  In  both  cases,  the  approaches  to  be  pursued  involve  use  of  the  vMR  and  the 
HSSP  efforts  to  model  decision  support  as  a  service. 

B. 6.  Evaluate  and  disseminate  program  status  and  progress 

Since  our  collaborative  process  is  intended  to  be  an  open  one,  a  key  dissemination  strategy  will  be 
through  use  of  the  web  portal  we  establish  for  the  Morningside  Initiative.  We  intend  to  promote  its  use 
through  panels  and  presentations  at  national  meetings  and  online  announcements.  Through 
instrumentation  of  the  web  portal  and  inclusion  of  Web  2.0  assessment  tools  which  are  part  of  the 
BioCore  portal  design,  we  will  track,  monitor  and  assess  content  growth/update,  and  assess  usability  of 
tools  and  processes.  We  will  also  monitor  cost  of  participation  of  each  site  and  of  coordination/central 
Morningside  Initiative  activities;  usage  logs  and  internal  adoption  by  sites  from  repository;  and 
governance  issues/conflicts/resolution,  and  will  publish  and  disseminate  our  results. 

C.  CURRENT  STATUS  AND  FUTURE  DIRECTIONS 

The  Morningside  Initiative  supports  the  following  Critical  Path  Tasks  identified  in  the  AMIA  Roadmap;  it 
creates  a  mechanism  whereby  an  ongoing  forum  for  dialogue,  consensus,  and  action  by  CDS  stake¬ 
holders  can  be  achieved;  promotes  dissemination  and  application  of  best  CDS  implementation  prac¬ 
tices;  demonstrates  the  feasibility,  scalability,  and  value  of  a  collaborative  approach  to  CDS  by  having 
specific,  standardized  tools  and  best  practices  publicly  available;  and  provides  a  forum  to  analyze  and 
generalize  lessons  learned  from  the  development  of  a  knowledge  repository  and  its  effects  in  furthering 
CDS. 

The  above  processes  have  been  going  on  for  approximately  eighteen  months,  and  the  functional  re¬ 
quirements,  metadata  tags,  submission  templates,  and  a  collection  of  diabetes  rules  knowledge  from 
the  participating  sites  have  been  analyzed.  These  serve  as  a  basis  for  a  current  effort  aimed  at  finaliz¬ 
ing  the  selection  of  a  software  and  hardware  platform  for  subsequent  build  out  and  development  of  the 
repository  and  tools,  and  gearing  up  the  knowledge  acquisition,  formalization,  and  management  tasks. 

We  believe  that  an  important  future  effort  will  be  authoritative  review  of  best  available  knowledge  that  is 
ready  for  widespread  use,  and  to  be  proactive  in  acquiring  this  new  knowledge,  formalizing  it,  and 
integrating  it  into  the  repository  to  facilitate  dissemination  and  adoption.  An  important  development, 
now  in  its  very  early  stages,  has  come  out  of  a  meeting  sponsored  by  AHRO  and  organized  by  HL7, 
called  “Bridging  the  Chasm”,  which  was  held  in  Washington,  DC,  April  19-21  (see: 
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http://www.hl7.org/btc.html .  This  meeting  brought  together  more  than  100  leaders  of  clinical  specialty 
societies  as  well  as  key  health  care  organizations  to  address,  among  other  topics,  the  question  of  how 
we  go  from  authoritative  collections  of  best  practice  knowledge  (such  as  AHRQ  Evidence-Based 
Practice  Centers,  the  Cochrane  Collection,  and  Comparative  Effectiveness  Research  analyses  and 
reports,  or  narrative  guidelines  based  on  them)  to  actually  changing  our  health  care  processes  through 
broad  dissemination  and  adoption.  One  question  is  whether  any  entity  could  serve  as  a  trusted 
authority  for  determining  which  knowledge  is  ready  for  “prime  time”,  fully  recognizing  how  politically 
fraught  such  an  activity  would  be.  Assuming  that  it  would  nonetheless  be  desirable  for  such  activity  to 
be  carried  out,  a  segment  of  the  discussion  focused  particularly  on  the  issue  of  specification  of  such 
knowledge  in  the  unambiguous,  focused  form  of  CDS  rules.  One  outcome  of  the  meeting  was  the 
establishment  of  a  new  effort,  called  the  Clinical  Information  Interchange  Collaborative  (CMC) 
(http://btc.hl7. org/index.php?title=Main_Page),  which  can  be  seen  in  a  sense  as  a  “meta-society"  that 
will  seek  to  develop  methods  for  inter-society  cooperation  to  establish  a  process  for  enabling 
authoritative,  respected  medical  knowledge  to  be  captured  and  made  available  in  a  form  that  facilitates 
adoption  (i.e.,  is  executable).  Thus  a  possible  future  direction  will  be  to  link  up  with  and  work  closely 
with  such  an  activity,  so  as  to  close  the  loop  between  identified  best  practice  and  implementation. 
Having  such  mechanisms  will  ultimately  lead  to  the  need  for  a  decision  in  terms  of  the  role  of  a  national 
shared  repository.  We  believe  that  the  original  content  from  a  variety  of  sources,  having  been 
normalized,  should  be  available  for  inspection  by  all  users.  But  this  is  of  primary  benefit  to  secondary 
adopters  that  have  needs  very  similar  to  the  contributors  or  the  wherewithal  to  conduct  review  of 
multiple  variations  and  do  the  necessary  adaptations  themselves.  There  is  a  larger  community  of 
potential  adopters  who  don’t  have  such  expertise.  Also,  there  is  continued  new  knowledge  arising  from 
clinical  trials,  EPC,  Cochrane,  and  CER  reports,  and  finding  its  way  into  guidelines  that  have  not  yet 
been  reviewed  for  implementability  or  relationship  to  existing  CDS.  Such  review  is  a  labor-intensive 
and  expensive  process.  Reviewing  evidence  from  clinical  trial  and  other  sources  for  application  to 
clinical  care  also  requires  unique  expertise  not  only  in  the  clinical  content  domain,  but  also  in  the 
evaluation  of  study  design. 

Large  healthcare  organizations  that  engage  in  developing  their  own  guidelines  devote  substantial 
resources  to  this  process.  Small  healthcare  institutions  such  as  individual  hospitals  and  small  group 
practices  rarely  have  the  resources  to  develop  their  own  sets  of  knowledge  content.  Even  large 
organizations  are  generally  not  able  to  produce  revisions  to  guidelines  more  often  than  every  few  years. 
Thus  this  task  may  be  an  important  role  for  a  future  national  CDS  initiative  to  fulfill. 

C.1  Sustainability 

Ultimately,  a  National-level  initiative  will  have  participants  in  both  public  (federal/non-federal)  and 
private  (commercial/non-commercial)  sectors,  and  with  potentially  many  kinds  of  stakeholders 
(providers,  payers,  professional  societies,  government  agencies,  standards  organizations,  knowledge 
providers,  and  health  systems  providers,  to  name  a  few).  One  model  for  sustainability  would  thus  be 
long-term  commitment  for  support  by  a  Federal  agency,  much  as  AHRQ  supports  the  EPCs.  An 
alternative  is  to  establish  a  means  for  such  an  initiative  to  obtain  support  from  its  constituency.  One 
model  is  that  used  by  membership  organizations,  such  as  AMIA  and  HL7.  These  have  both  institutional 
and  individual  membership  categories,  with  benefits  associated  with  each,  but  do  not  limit  access  of 
members  to  their  products  and  services  based  on  type  of  user.  Rather,  the  fee  model  essentially  offers 
"quantity  discounts”  based  on  numbers  of  members.  Such  organizations  have  boards  of  directors  that 
govern  them,  and  which  are  open  to  broad  participation  through  democratic  processes. 


The  Morningside  Initiative  is  a  first  step  in  bringing  together  on  a  voluntary  basis  organizations  that 
have  taken  a  leadership  role  in  developing,  deploying,  and  demonstrating  the  value  of  CDS  for  health 
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care,  to  pool  their  expertise  for  the  purpose  of  jump-starting  a  national  knowledge  sharing  activity.  The 
road  ahead  is  long,  but  we  have  already  learned  that  much  can  be  gained  by  traveling  together. 


DISCLAIMER 

The  KMR  project  is  supported  by  Award  Number:  W81XWH-06-2-0074,  administered  through  the  U.S. 

Army  Medical  Research  Acquisition  Activity,  820  Chandler  Street,  Fort  Detrick,  MD  21702-5014. 

The  opinions  of  the  authors  do  not  necessarily  state  or  reflect  those  of  their  respective  employers, 

including  the  Department  of  Veterans  Affairs  or  the  Department  of  Defense  of  the  United  States 

Government,  and  shall  not  be  used  for  advertising  or  product  endorsement  purposes. 
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Tables  and  Figures 


Table  1.  Condensed  functional  requirements  for  a  Knowledge  Repository.  Requirement  categories  and 
examples  of  functional  requirements  are  included.  The  requirements  seek  to  capture  elements  of  the 
knowledge  model,  the  knowledge  authoring  environment,  the  knowledge  sharing  environment,  and  the 
repository  itself.  And  as-yet-unrealized  goal  is  to  specify  functional  requirements  for  a  knowledge 
execution  component  of  this  environment. 


Knowledge  Delivery  Model:  Requirements 

Capability 

Discussion 

The  system  will  function  using  Symbolic  Variables 

The  system  will  function  using  Objects  (again  symboli¬ 
cally) 

A  goal  is  to  separate  the  logical  manipulation  of  sym¬ 
bolic  variables  from  the  mapping  of  those  symbolic  vari¬ 
ables  onto  (local)  clinical  data.  Identifiers  for  symbolic 
variables  are  selected  to  be  consistent  with  the  thought 
processes  and  language  of  clinicians  (i.e 
last_serum_glucose). 

Time  will  be  a  Component  of  Variable/Object  Collec¬ 
tions. 

All  clinical  data  should  retain  its  timestamp  when  ren¬ 
dered  as  a  variable  in  decision  logic.  The  timestamp  is 
chosen  to  represent  the  point  in  time  when  the  data 
value  was  current.  (A  discussion  of  time  ranges  and 
other,  non-point  time  values  will  be  postponed.) 

■  ■  • 

•  t  • 

Knowledge  Repository 

Capability 

Discussion 

Allows  storage  (upload)  of  decision  modules. 

Hopefully  through  a  process  that  "normalizes"  the 
chunks  of  logic.  This  could  be  accomplished  by  mapping 
onto  a  standard,  interchange  format. 

Allows  retrieval  (download)  of  decision  modules  in  a 
read-only  mode. 

This  is  for  download  of  modules  to  test  and  perhaps  use 
in  a  recipient  system. 

Supports  check  out  of  decision  modules  explicitly  for 
either  editing  or  edit-free  reviewing. 

The  system  would  allow  for  checkout  of  logic  or  collec¬ 
tions  of  logic  for  editing  and  other  management  func¬ 
tions.  This  would  require  an  "author"  level  authoriza¬ 
tion.  When  decision  logic  is  checked  out  for  editing  by 
one  author,  it  cannot  be  checked  out  for  editing  by  oth¬ 
er  authors.  When  altered  logic  is  checked  back  in,  it 
would  receive  a  new  version  number. 

•  ■  • 

■  ■  • 
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Knowledge  Authoring/Maintenance 


Capability 


Supports  views  of  decision  modules  in  the  repository's 
native  (XML)  markup. 

Supports  views  of  decision  modules  in  "user  friendly" 
text-based  format. 

Supports  views  of  decision  modules  in  graphical  format. 


Discussion 


The  assumption  is  that,  at  least  part  of  the  decision 
modules  will  be  stored  in  a  XML-tagged  data  model. 

Converters  should  be  present  that  will  display  the  deci¬ 
sion  logic  and  metadata  in  an  easily  read  textual  format 

Trees  or  flow  diagrams  can  show  the  relationship  be¬ 
tween  parts  of  the  decision  logic  (families  of  rules  or 
modules)  used  to  create  more  complex,  decision  output 
(guidelines). 


Knowledge  Sharing  Service 


Capability 


Supports  conversion  from  local  knowledge  models  to  a 
repository  specific,  medical  rules  interchange  format 
(MRIF). 

Supports  conversion  from  the  repository-specific,  know¬ 
ledge  interchange  format  into  forms  executable  in  mul¬ 
tiple  knowledge  execution  environments. 

Translators  should  accommodate  rule  models  including 
all  standard  logical  functions/structures. 


Discussion 


The  goal  is  to  find  a  robust  "Interlingua"  that  will  facili¬ 
tate  moving  logical  constructs  from  one  executable 
form  to  another. 

Ideally,  these  knowledge  execution  environments 
would  all  have  a  local  expression  of  the  executable  form 
in  XML.  This  would  allow  most  translations  to  be  done 
using  XSLTs. 

A  standard  vocabulary  of  logical  structures  will  need  to 
be  represented  (Add  Appendix). 


Knowledge  Execution  Environment 
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Table  2.  Examples  of  metadata  for  indexing  content  in  a  knowledge  repository.  The  collection  is 
derived  from  metadata  described  in  a  number  of  categorization  schemes  for  computable  medical 
knowledge. 


Metadata  Title 

Metadata  Description 

Orig.  Metadata  Source 

Resource  Title 

1  ^  '-v  •■-.*&=-  _  - 

Title  of  module  of  clinical  logic. 

•  In  Arden 

•  In  Morningside  Tem¬ 
plate 

File  Identifier  (URI) 

Uniform  Resource  Locator(for  storage);  replaces 
filename  (Arden) 

•  In  Arden 

•  In  Morningside  Tem¬ 
plate 

UNID 

Unique  identifier  for  indexing  through  a  terminology 
service  for  instance. 

•  In  Morningside  Tem¬ 
plate 

Version  and 

Branch  ID 

A  number  indicating  the  version.  In  the  context  of  a 
source  repository,  this  might  capture  new  branches  as 
versioning  generates  alternate  directions  in  the  logic. 

•  In  Arden 

•  In  Morningside  Tem¬ 
plate 

Submission/Revision  Dates/ 
Branching  dates 

The  date  associated  with  submission  of  this  version. 

•  In  Arden 

•  In  Morningside  Tem¬ 
plate 

Purpose 

Statement  of  the  goal  of  the  logic  (free  text).  May 
also  provide  tag  references  to  a  controlled  taxonomy 
of  purposes. 

•  In  Arden 

•  In  Morningside  Tem¬ 
plate 

•  •  • 

•  •  • 

•  •  • 
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Fig.  1.  General  framework  for  the  Momingside  Initiative 
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Fig-  2.  Table  showing  example  rules  from  Partners  Healthcare,  Intermountain  Healthcare,  Veterans 
Administration,  and  Kaiser  Permanente  dealing  with  HgbAlc  assessment.  Columns  indicate  individual 
rules  (or  disjunctive  clauses  of  rules)  by  institution.  The  conditions  potentially  evaluated  are  enumerated 
in  the  blue  section,  with  those  included  in  a  particular  rule  indicated  by  the  value  needed  for  satisfaction 
(N  or  Y).  The  actions  to  be  performed  (sending  of  a  message  or  ordering  of  a  test)  on  satisfaction  of  the 
conditions  for  a  rule  are  indicated  in  the  red  and  yellow  sections  of  that  column  by  the  presence  of  a  Y. 


— 

HGBA1  ^ASSESSMENT 

PHS 

IH 

VA 

KP 

gjj 

BE 

KflJ 

H 

in 

D 

m 

ID 

KB 

Most  recent  HgbAlc  <  (or  <=)  9  months  old 

N 

Most  recent  HqhAlc  <  (o>  <«)  11  months  old 

'KB 

Most  recent  HqbAlc  <  (or  <f)  6  months  otd 

EH 

KB 

Most  recent  HqbAlc  <  (or  <=)  S  months  otd 

KB 

KB 

KB 

Most  recent  HqbAlc  <  (or  3  months  old 

KB 

KB 

_ 

KB 

KB 

-■VAY--' 

Y 

Y 

mm 

KB 

KB 

...4  5 

HgbAlc  documented  elsewhere 

L L 

KB 

HqbAlc  ordered  within  last  7  days 

hhi 

bhi 

hub 

HI 

KB 

Patient  is  overdue  for  HbAlc  (rec:  q  6  months) 

Y 

Missmq  HqhAlc  data  (should  be  done  on  all  Patients  with  Diabetes) 

Y 

Y 

Diabetics  need  at  least  annua!  Hemcgtofrn  A1C  testing. 

i gw 

B3I 

C— i 

Y 

Hemogtobm  A1C  requited  annually  tor  all  diabetic  patients  Patients  with  levels  >7.0  should  be 
considered  for  more  frequent  testing. 

Y 

Patient  is  almost  due  for  HbAlc  (rec  q  6  months) 

Y 

All  Patients  with  Diabetes  and  HgbAlc  between  7  and  8  should  ha/e  a  HgbAlc  every  3  months 

Y 

Ail  Patients  with  Diabetes  and  HqbAlc  >  8  should  have  a  HqbAlc  every  3  months  until  under  8  0 

Y 

Last  HbAlc  is  high,  and  patient  is  overdue  for  HbAlc  (rec  q  3  months) 

Y 

Last  HbAlc  is  done  within  3  months,  but  hiqh 

feSBS 

Y 

Patient  refused  Hemoglobin  A1C  testing  Ask  aqatn  in  6  months. 

Y 

LAB 

Order  A1C  test  today 

V 

Y 

Y 

Order  A1C  test  in  3  months 

_ 

Y 

Y 

_ 

_ 

_ 

Accelerating  the  Translation  of  Knowledge  into  Clinical  Decision 
Support:  Four  National  Demonstration  Projects 

Blackford  Middleton,  MD,  MPH,  MSe%  Robert  Greenes,  MD,  PhDb,  Emory  Fry,  MDC, 
Klaus-Peter  Adiassnig,  PhD,  MScd,Insook  Cho,  PhD,  RNC 

“  Clinical  Informatics  Research  and  Development,  Partners  HealtliCare  System,  Harvard  Medical  School,  Boston,  MA,  USA 
b  Department  of  Biomedical  Informatics.  Arizona  State  University,  Arizona  Biomedical  Collaborative.  Phoenix,  AZ,  USA 
'  Uniformed  Services  University  of  the  Health  Sciences,  F.  Edward  Hebert  School  of  Medicine,  Bethesda.  MD,  USA 
d  Core  Unit  for  Medical  Statistics  and  Informatics.  Medical  University  of  Vienna,  Austria 
e  Department  of  Nursing,  Inha  University,  Younghyun-dong,  Nam-gu,  Incheon.  South  Korea 


Abstract  and  Objective 

Electronic  health  records  (EHRs),  when  used  effectively,  can 
improve  the  safety  and  quality  of  health  care.  For  maximum 
benefit,  however.  EHRs  must  be  paired  with  clinical  decision 
support  (CDS)  systems  to  effectively  in  fluence  physician  be¬ 
havior.  Wider  adoption  of  decision  support  has  been  held 
back  by  a  variety  of  issues,  including: 

•  Difficulty  translating  medical  knowledge  and  guide¬ 
lines  into  a  form  that  can  be  used  by  EHRs  and  PHRs. 

•  Technical  challenges  in  developing  a  standard  repre¬ 
sentation  for  CDS  content. 

•  Absence  of  a  central  knowledge  repository  where  hu¬ 
man  readable  and  executable  guideline  knowledge  can 
be  shared  and  stored. 

•  Challenges  in  integrating  decision  support  into  the 
clinical  workflow  and  other  baniers  to  IT  adoption. 

This  pane!  will  explore  challenges  to  fostering  widespread 
adoption  of  clinical  decision  support  at  scale  -  across  na¬ 
tional  demonstration  projects  from  3  countries:  USA.  Austria, 
and  Korea. 

Keywords:  Clinical  decision  support  systems,  personal  health 
record,  electronic  health  record. 

Panel  description 

The  panel  will  present  the  work  from  three  countries  targeted 
at  accelerating  the  translation  of  knowledge  into  practice  via 
clinical  decision  support  in  healthcare  information  technol¬ 
ogy:  the  CDS  Consortium,  the  Distributed  Decision  Support 
and  Knowledge  Management  Project,  the  Momingside  Initia¬ 
tive  (USA),  the  CDS  Architecture  Project  for  Korea,  and  the 
MedExpertAVWW  and  related  systems  in  Austria.  Lead  in¬ 
vestigators  from  each  will  provide  an  update  on  progress  and 
identification  of  challenges  for  practical  implementation. 

The  objectives  of  the  panel  are  to  foster  discussion  and  insight 
into  handling  the  issues  that  continue  to  impede  widespread 


adoption  of  clinical  decision  support,  and  to  present  opportu¬ 
nities  to  coordinate  activities  amongst  the  initiatives. 

Panel  organizer  and  participants 

Blackford  Middleton,  MD,  MPH,  MSc 

Corporate  Director,  Clinical  Informatics  R&D,  Chairman, 
Center  for  IT  Leadership,  Partners  Healthcare  System,  Har¬ 
vard  Medical  School,  Boston,  MA,  USA 

The  Clinical  Decision  Support  Consortium  (CDSC) 

The  goal  of  the  CDSC  is  to  assess,  define,  demonstrate,  and 
evaluate  best  practices  for  knowledge  management  and  clini¬ 
cal  decision  support  in  healthcare  information  technology  (IT) 
at  scale  —  across  multiple  ambulatory  care  settings  and  EHR 
technology'  platforms.  To  achieve  this  goal,  the  CDS  Consor¬ 
tium  is  carrying  out  a  broad  array  of  activities  over  the  next 
two  to  five  years  across  member  sites  of  the  CDS  Consortium: 

•  Carry  out  a  survey  of  knowledge  management  practices 

•  Translate  guidelines  into  actionable  decision  support  tools 

•  Build  a  knowledge  portal  and  repository  (KPR) 

•  Develop  CDS  Web  Services 

•  Carry  out  demonstrations  of  CDS  across  CDSC  sites 

•  Build  CDS  performance  measures  and  “dashboards”  to 
measure  the  success  of  our  CDS 

•  Evaluate  our  work  and  demonstrations,  and  ake  recom¬ 
mendations  to  CCHIT,  HITSP,  the  vendor  community 

Robert  Greenes,  MD,  PhD 

Ira  A.  Fulton  Chair  and  Professor,  Department  of  Biomedical 
Informatics,  Arizona  State  University,  Arizona  Biomedical 
Collaborative,  Phoenix,  AZ,  USA 

The  Morningside  Initiative 


The  premise  underlying  the  establishment  of  the  Momingside 
Initiative  is  that  through  the  initial  collaboration  of  a  small 
group  of  key,  committed  participants,  a  model  can  be  devel¬ 
oped  and  refined  for  sharing  of  CDS  knowledge  that  ad¬ 
dresses  three  key  aspects  of  the  process: 

•  The  organizational  framework  under  which  disparate  or¬ 
ganizations  can  contribute  their  expertise  and  knowledge 
and  obtain  the  benefits  of  access  to  shared  knowledge, 
that  can  be  scaled  up  to  include  a  broad  range  of  partici¬ 
pants  on  a  national  (or  international)  scale 

•  Content  acquisition,  representation,  and  management 
processes  that  are  effective  and  can  be  expanded  in 
scope  of  domains  and  knowledge  types  included 

•  Technical  capabilities  to  support  content  acquisition,  ed¬ 
iting  and  review,  representation  and  annotation,  incorpo¬ 
ration  into  the  repository,  retrieval,  and  secondary  use 

Emory  Fry,  MD 

Assistant  Professor  of  Pediatrics  and  Medical  Informatics, 
Uniformed  Services  University  of  the  Health  Sciences,  F. 
Edward  Hebert  School  of  Medicine,  Bethesda,  MD,  USA 

The  Distributed  Decision  Support  and  Knowledge  Man¬ 
agement  (DDSS-KMR)  Project 

The  DDSS-KMR  Project  seeks  to  develop  a  collaborative 
open-source  community  that  collectively  contributes  to  the 
legal,  administrative,  and  technical  solutions  required  to  ad¬ 
vance  clinical  decision  support,  patient  safety,  and  quality 
improvement.  It  supports  this  primary  objective  by  providing 
a  run-time  infrastructure  for  clinical  decision  support  using 
the  FHA  NHIN-CONNECT  architecture  developed  in  the 
USA. 

CONNECT,  a  fully  functional  service-oriented-architecture, 
implements  a  flexible,  standards-based,  open-source  solution 
that  enables  healthcare  entities  to  connect  existing  health  in¬ 
formation  systems  to  the  Nationwide  Health  Information  Net¬ 
work.  The  CONNECT  services  supplement  existing  function¬ 
ality  delivering  components  back  to  the  connectopen- 
suurce.org  effort  in  the  following  areas: 

•  The  core  clinical  decision  support  infrastructure  is  com¬ 
prised  of  the  runtime  Distributed  Decision  Support  Ser¬ 
vices  (DDSS)  engine  and  the  Knowledge  Management 
Repository  (KMR). 

•  Patient  Services  delivers  a  fully  integrated  collaboration 
environment  having  many  of  the  functional  capabilities 
that  productivity  tools  such  MS  Outlook  enable,  including 
email,  appointing,  task  lists,  etc. 

•  Provider  Sendees  exposes  an  authoring  environment 
(Workbench)  for  constructing  semantically  constrained 
clinical  rules/guidelines,  and  provides  notification  ser¬ 
vices  (MedAlert  /  Universal  Inbox)  for  responding  to 
CDS  recommendations.  Providers  will  have  the  capability 
to  create  highly  personalized  treatment  plans  for  patients 
with  common  chronic  conditions  and  for  collaborating 
with  them  using  intuitive  and  workflow  appropriate  ways. 


Klaus-Peter  Adlassnig,  PhD,  MSc 

Professor  of  Medical  Informatics,  Head  of  the  Section  on 
Medical  Expert  and  Knowledge-Based  Systems,  Core  Unit  for 
Medical  Statistics  and  Informatics,  Medical  University  of  Vi¬ 
enna/Austria 

The  Austrian  Providing  Solutions  for  Clinical  Decision 
Support”  Project 

The  Medical  University  of  Vienna  and  the  Vienna  General 
Hospital  initiated  and  continuously  support  the  broad  intro¬ 
duction  of  decision  support  systems  in  the  clinical  practice  of 
their  and  associated  institutions.  In  the  course  of  this  project, 
the  following  goals  have  already  been  achieved: 

•  Development  and  implementation  of  a  service-oriented, 
Arden-Syntax-based  clinical  decision  support  framework 
with  proven  transferability,  easy  extensibility,  and  broad 
integratebility. 

•  Development  and  implementation  of  the 
Moni/Surveillance-ICU  and  -NICU  systems  (total  of  132 
beds)  for  the  fully  automated  early  identification  and  con¬ 
tinuous  monitoring  of  hospital-acquired  infections  in  in¬ 
tensive  and  neonatal  care  units  (ICUs  +  NICUs). 

•  Involvement  of  the  nationwide  ELGA  project  coordinated 
by  the  Austrian  government,  aimed  at  establishing  Aus¬ 
tria-wide  access  to  patient  administrative  and  medical  (at 
present,  laboratory  and  radiology)  data.  Provider  access 
to  complement  core-ELGA  with  clinical  decision  support 
is  scheduled. 

Insook  Clio,  PhD,  RN 

Associate  Professor,  Maternity  Nursing  &  Nursing  Informat¬ 
ics,  Inha  University,  Younghyun-dong,  Nam-gu,  Incheon, 
South  Korea. 

CDS  Architecture  for  Korea 

The  Korean  government  has  initiated  the  efforts  to  secure  the 
healthcare  accessibility  and  efficiency  anytime  and  anywhere 
through  the  nationwide  healthcare  information  system  by 
2010.  Clinical  decision  support  (CDS)  service  was  one  project 
to  design  and  implement  standards-based  interoperable  CDS 
capabilities  in  the  EHR  context. 

A  CDS  service  architecture  and  several  components  have 
been  developed  in  conjunction  with  the  other  EFIR  activities; 
defining  national  level's  EHR  architecture,  developing  com¬ 
mon  clinical  content  model  and  healthcare  terminologies,  and 
identifying  health  information  exchange  infrastructure.  This 
process  resulted  in  implementing  and  evaluating  a  prototype 
CDS  service  for  hypertension  management  in  ambulatory  care 
settings.  The  process  also  has  followed  by  pilot  demonstration 
project  initiatives  in  the  three  hospitals.  These  projects  will 
contribute  to  demonstrate  the  feasibility  of  implementing  the 
CDS  architecture  outside  of  this  research  team,  in  a  systematic 
manner  that  can  drive  predictable  improvements  in  health  out¬ 
comes  and  be  ready  deployed  in  a  variety  of  health  care  set¬ 
tings. 
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Introduction 


Thomson  Reuters  is  pleased  to  respond  to  the  National  Resource  Center  for  Health  IT,  Domain  2  Request 
for  Task  Order  #  4.  There  are  strong  synergies  between  this  task  order  and  the  Thomson  Reuters 
commitment  to  providing  professionals  with  “knowledge  to  act.”  We  are  especially  well-versed  in  the 
healthcare  market  segment,  a  primary  component  of  our  business  that  includes  empowering  healthcare 
providers  with  relevant,  evidence-based  knowledge  to  drive  measurable  performance  improvement.  The 
team  we  have  assembled  has  over  three  decades  of  pioneering  experience  in  Clinical  Decision  Support 
(CDS)  in  general,  and  with  the  production  and  deployment  of  clinical  guidelines  in  particular.  We 
propose  to  support  all  AHRQ  activities  related  to  the  production  of  Hardened  Rules  for  Clinical  Decision 
Support  and  do  not  deviate  from  the  Task  Order  Statement  of  Work  (SOW).  In  particular,  we  will 
perform  tasks  one  through  eight  as  described  in  this  proposal  within  the  time  limits  specified  in  the 
RFTO.  Thomson  Reuters  and  our  subcontractors  share  AHRQ’s  passion  for  improving  healthcare  quality 
and  reducing  costs,  and  our  combined  skills  make  us  an  exceptionally  effective  team.  This  proposal 
outlines  our  approach  for  executing  the  Task  Order  objectives.  We  have  suggested  enhancements  to 
selected  tasks  based  on  lessons  learned  from  our  combined  experience  with  related  activities.  Our  team  is 
eager  to  support  this  important  endeavor. 

A.  Understanding  of  the  Project 

The  Task  Order  objective  is  to  generate  logic  statements  that  are  derived  from  evidence  based  clinical 
recommendations  and  that  can  be  widely  executed  through  health  IT.  The  initial  scope  for  such  CDS  rule 
development  is  to  convert  A  and  B  recommendations  from  the  USPSTF,  and  at  least  one  other  widely 
accepted,  evidence  based,  actionable  guideline  into  logic  statements.  This  material  will  provide  a  “seed” 
collection  of  CDS  rules  that  can  be  used  readily  by  EHR  suppliers  and  local  implementers.  These 
deliverables  are  an  intermediate  step  toward  the  broader  goal  of  ensuring  that  CDS  rules  and  related  tools 
(covering  these  and  additional  topics)  optimally  support  medical  decision  making  in  practice  and  help 
drive  widespread  healthcare  performance  improvement. 
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Despite  thoughtful  efforts  over  the  last  three  decades  to  translate  clinical  guidelines  into  CDS  rules,  there 
has  not  been  widespread  and  successful  use  of  such  rules  to  improve  patient  care.  AHRQ  has  played  a  key 
role  in  recent  initiatives  to  define  and  execute  on  approaches  for  more  effective  CDS1,  and  this  task  order 
is  a  next  logical  step  in  this  work.  Several  recent  developments  address  prior  obstacles  to  widely  useful 
CDS  rules,  and  set  the  stage  for  project  success.  These  include:  growing  understanding  about  how  to 
translate  clinical  guidance  into  executable  logic  statements  (e.g.,  generated  by  AHRQ’s  CDS  Initiative 
and  related  sources2"1'4'5'6'7'8'9);  powerful  incentives  for  providers  to  leverage  information  technology  to 
ensure  that  critical  clinical  interventions  always  happen  when  appropriate;10  emerging  best  practices  for 
seamlessly  incorporating  CDS  interventions  into  workflow  to  improve  care  processes  and  outcomes;11 
and  a  major  drive  by  health  policymakers  and  others  to  standardize  clinical  information  system 


1  See  Webpage  on  AHRQ’s  CDS  Initiative 

(littp:/healthit.ahra.uov/nortal/server.r)t'?onen=.5 12&obilD=654& Panel  D=  1 3665&mode=2&cachcd-~true&wtau- wta 
g666);  see  also  AHRQ’s  participation  in  developing  a  Roadmap  for  National  Action  on  Clinical  Decision  Support. 
Osheroff,  Teich,  Middleton  et  al.  (2006)  -  http://\vww.amia.oru/inside/initiatives/cds 

'Wang  D,  Peleg  M,  Tu  SW,  Shortliffe  EH,  Greenes  RA.  Representation  of  clinical  practice  guidelines  for  computer- 
based  implementations.  Proc  MED1NFO  2001,  London,  UK,  September,  200 1 ;  10(Pt  l):285-289. 

I  Boxwala  AA,  Peleg  M,  Tu  S,  Ogunyenti  O,  Zeng  QT,  Wang  D,  Patel  VL,  Greenes  RA,  Shortliffe  EH.  GLIF3:  A 
representation  format  for  sharable  computer-interpretable  clinical  practice  guidelines.  J Biomed Inform.  2004  Jun; 
37(3):  147-61 . 

4  Lobach  DF,  Kawamoto  K,  Anstrom  KJ,  Russell  ML,  Woods  P,  Smith  D.  Development,  deployment,  and  usability 
of  a  point-of-care  decision  support  system  for  chronic  disease  management  using  the  recently-approved  HL7 
decision  support  service  standard.  Stud  Health  Technol  Inform.  2007;  129(Pt  2):86 1-5. 
standard.  Stud  Health  Technol  Inform.  2007;  129(Pt  2):861-5. 

s  Greenes  RA,  Sordo  M,  Zaccagnini  D,  Meyer  M,  Kupennan  GJ.  Design  of  a  standards-based  external  rules  engine 
for  decision  support  in  a  variety  of  application  contexts:  Report  of  a  feasibility  study  at  Partners  Healthcare  System. 
Proc  MEDINFO  2004,  San  Francisco,  CA,  IMIA:  Amsterdam;  2004:61 1-615. 

b  Sordo  M,  Boxwala  AA,  Ogunyemi  O,  Greenes  RA.  Description  and  status  update  on  GELLO:  A  proposed 
standardized  object-oriented  expression  language  for  clinical  decision  support.  Proc  MEDINFO  2004,  San 
Francisco,  CA,  1M1A:  Amsterdam;  2004:  164-168. 

7  Haug  PJ,  Gardner  RM,  Evans  RS,  Rocha  B,  Rocha  R.  Hospital-Based  Decision  Support.  In  "Clinical  Decision 
Support  Systems:  Theory  and  Practice  (Second  Edition)"  Eta  S.  Bemer,  Editor.  Springer-Verlag,  2006,  Chapter  8; 
pages  159  to  189. 

8  Thompson  DI,  Classen  DC,  Haug  PJ.  EMRs  in  the  Fourth  Stage.  JHIM  (2007);  21(3): 

49-60. 

9  Kim  S,  Haug  PJ,  Rocha  RA,  Choi  I.  Modeling  the  Arden  Syntax  for  medical  decisions  in  XML.  Int  J  Med  Inform. 
2008  Oct;77(10):650-6. 

10  See,  for  example,  “Medicare  and  Medicaid  Health  Information  Technology:  Title  IV  of  the  ARRA”  at 
www.cms.hhs.uov/Recoverv/l  1  HealthIT.asp.  and  the  “Meaningful  Use  Matrix”  at  healthit.hhs.nov.  which  specifies 
that  providers  must  implement  a  CDS  rule  to  achieve  meaningful  use 

II  See,  for  example,  Osheroff,  JA,  ed.  Improving  medication  use  and  outcomes  with  CDS:  a  step-by-step  guide. 
HIMSS.  2009,  and  other  CDS  implementer  guidebooks  in  the  series:  www. himss.org/cdsguide. 
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functionality  and  interoperability.13 

These  favorable  developments  notwithstanding,  there  are  still  significant  challenges  associated  with 
producing  deliverables  under  this  task  order  that  will  be  widely  used  and  useful.  For  example,  there  are 
still  no  widely  adopted  standards  for  the  format  or  other  CDS  rule  features  that  would  ensure  widespread 
adoptability.  This  makes  a  successful  approach  to  Tasks  5,  6,  and  7  -  that  is,  assessing  and  synthesizing 
prior  work,  gaining  feedback  from  key  stakeholders,  and  producing  the  structured,  coded  logic  statements 
-  particularly  critical.  Likewise,  the  related  administration,  quality  assurance,  coordination  and 
dissemination  tasks  must  be  handled  carefully  to  ensure  a  solid  foundation  for  scaling  and  enhancing 
these  innovative  work  products. 

Members  of  the  proposed  Thomson  Reuters  team  have  played  leading  roles  in  many  of  the  enabling  CDS 
developments  that  set  the  stage  for  successful  execution  of  this  task  order,  and  Thomson  Reuters  has  a 
long  history  of  successful  support  for  major  AHRQ  initiatives.  Our  overall  approach  will  combine  expert 
selection  and  utilization  of  the  best  available  software  tools,  hands-on  expertise  of  pioneering  health 
informaticists,  consensus  building  from  a  broad  array  of  stakeholders,  and  close  collaboration  with 
AHRQ.  We  have  secured  commitment  from  the  leading  societies  representing  EHR  vendors  and  clinical 
information  system  implementers  to  ensure  that  work  products  will  be  deployed  broadly  and  provide  high 
value.  These  and  other  details  of  our  approach  are  outlined  below. 

B.  Technical  Approach  and  Schedule 

The  RFTO  lays  out  an  alternative  to  the  multiple  uncoordinated  efforts  currently  underway  by  the  broad 
community  engaged  in  CDS  development  and  implementation.  The  Task  Order  is  aimed  at  creating  a  set 
of  practical  deliverables  that  will  foster  widespread  adoption  and  successful  use.  Over  time,  refinement 
cycles  and  scope  expansion  will  improve  the  rule  set  robustness.  Our  proposed  approach  to  this  task  order 
is  described  in  detail  below.  The  following  deliverable  table  adheres  to  the  milestones  and  deliverables 
listed  in  the  RFTO  and  provides  a  proposed  task  schedule. 

12  For  example,  HITSP,  ONC.  HIT  Policy  Committee,  HIT  Standards  Committee,  CCHIT,  and  others.  More  at 
healthit.hhs.gov/portal/server.pt  -  see  ‘Standards  and  Certification. 


3 


Table  1.  Proposed  Project  Deliverable  Schedule 


Deliverable  #s 

Task 

Milestone/Deliverable  Description 

Due  Date 

#1 

1.1 

Kickoff  Meeting 

9/30/09 

#2 

1.2 

Work  Breakdown  Structure 

10/6/09 

#3 

1.3 

Project  Plan 

10/20/09 

#4-7 

1.4 

Quarterly  Progress  Reports 

1/8/10,  4/9/10,  7/9/10,  9/24/10 

#8-19 

1.5 

Monthly  Meetings  and  Related  Materials 

10/12/09,  11/16/09,  12/14/09,  1/11/10, 
2/16/10,  3/15/10, 4/12/10,  5/17/10, 
6/14/10,  7/19/10,  8/16/10,  9/13/10 

#20 

2.3 

Standard  Operating  Procedures 

8/6/10 

#21 

4.2 

508  Compliance  Plan 

10/21/09 

#22 

5.2 

Summary  Report  of  Background 
Assessment  and  Synthesis 

1 1/20/09 

#23-26 

6.1 

Attend  CDS  Collaborator  Meetings 

Hypothetical  dates:  1 1/2/09,  2/1/10, 
5/3/10,  8/2/10 

#27-30 

6.3 

Summary  of  Feedback  from  CDS 
Collaborator  Meetings 

One  week  after  hypothetical  dates 
above:  1 1/9/09,  2/8/10,  5/7/10,  8/6/10 

#31 

7.1 

Proposed  Guidelines  and  Methods 

11/20/09 

#32 

mm 

Draft  Logic  Statements 

On  a  periodic  basis  from  3/8/10 
through  6/28/10 

#33 

7.3 

Final  Logic  Statements 

7/23/10 

#34 

8.1 

Draft  Final  Report 

8/20/10 

#35 

8.2 

Final  Report 

9/10/10 

Our  planned  approach  to  this  task  features  four  main  development  stages:  1)  production  set-up,  2) 


production  testing,  3)  batch  production,  and  4)  submission  of  final  deliverables  (see  Figure  1).  We  explain 
each  of  the  proposed  steps  in  further  detail  in  the  descriptions  of  specific  tasks  that  follow. 


Figure  1.  High  Level  Approach 


Production  Set-Up 


Production 

Testing 


I  Select  Guideline  for 


Batch  Production  Final  Deliverables 


Run  Batch  1 


Specific  Tasks 
Task  1.  Administration 

Thomson  Reuters  will  manage  and  provide  direct  oversight  and  quality  assurance  for  all  aspects  of  this 
project  by  developing  the  project  plan;  leading  project  meetings  with  AHRQ  and  the  Domain  1 
Contractor;  providing  regular  progress  reports  to  AHRQ  and  the  CDS  Collaborator;  and  overseeing 
work  performed  by  our  subcontractors.  The  numbers  below  reflect  our  subtask  organization  and 
correspond  to  our  proposed  budget. 

1.1.  Kickoff  Call:  We  will  coordinate  with  the  AHRQ  Task  Order  Officer  (TOO)  on  the  agenda  for  the 
initial  planning  meeting.  Goals  for  the  call  will  include  clarifying  the  scope  of  work,  deliverables,  and 
timeline;  delineating  the  roles  and  responsibilities  of  the  Thomson  Reuters  team;  and  establishing 
communication  protocols  between  AHRQ,  the  Domain  1  Contractor,  and  the  project  team. 

1.2  -  1.3.  Planning  Tools  and  Project  Plan:  Thomson  Reuters  will  develop  planning  tools  and  a  project 
plan  using  Microsoft  Office  Project  (MSOP).  We  will  provide  the  TOO  a  timeline  that  includes  a  draft 
Work  Breakdown  Structure  (WBS) — the  structure  for  formal  accountability  to  the  government.  Starting 
with  the  proposed  deliverable  schedule,  we  will  lay  out  detailed  steps  within  the  WBS  categories  for  our 
internal  management  purposes,  evaluate  proposed  task  durations,  assess  task  dependencies,  confirm 
milestones  and  deliverables,  and  revise  the  project  plan.  These  data  will  be  entered,  tracked,  and 
presented  via  MSOP  2003  for  the  duration  of  the  project.  Within  three  weeks  of  the  kickoff  call,  the 
MSOP  Plan  will  be  delivered  to  the  TOO  as  a  single  file  for  tracking  project  progress  and  deliverables. 
1.4.  Progress  Reports:  Thomson  Reuters  will  develop  a  progress  report  template  that  lists  1)  the 
quarterly  task  status  of  milestones  and  deliverables  relative  to  the  timeline;  2)  items  inspected  for  quality 
control  by  month;  3)  progress  on  the  508  compliance  requirements;  4)  project  expenditures  relative  to  the 
budget  by  quarter;  5)  any  significant  risks  to  project  timelines  and  proposed  solutions  to  mitigate  the 
risks;  6)  a  summary  of  work  planned  for  the  next  quarter;  and  7)  updated  MSOP  documents.  We  will 
submit  the  progress  report  within  10  days  of  the  end  of  each  quarter  using  the  approved  format. 
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1.5.  Monthly  Planning  Meetings:  Thomson  Reuters  will  coordinate  monthly  calls  with  the  Principal 
Investigator,  the  Project  Manager,  the  Management  Advisor  (a  senior  administrator  with  extensive 
government  project  experience),  key  subcontractors,  the  AHRQ  TOO  and  other  designated  Agency  staff, 
and  the  Domain  1  contractor.  During  the  meetings,  we  will  discuss  the  status  of  active  tasks,  decisions 
needed  from  AHRQ,  and  cross-domain  issues.  Prior  to  each  meeting,  we  will  provide  an  agenda  and 
handouts  for  AHRQ  review.  After  each  meeting,  we  will  summarize  decisions  and  action  items  from  the 
call  and  distribute  the  information  to  attendees  and  the  project  team. 

Task  2.  Quality  Control  (QC)  and  Standard  Operating  Procedures  (SOP) 

Thomson  Reuters  will  produce  the  quality  assurance  plan,  manage  the  quality  control  inspections,  and 
coordinate  and  develop  a  Standard  Operating  Procedures  document. 

2.1.  Quality  Assurance  Plan:  To  provide  AHRQ  with  clear  and  concise  technical  products,  two  types  of 
quality  control  efforts  are  required.  The  first  will  be  for  technical  accuracy,  appropriateness,  and  value, 
requiring  clinical  and  informatics  expertise;  the  other  for  correctness  and  readability.  Our  quality  control 
protocol  will  include  ongoing  QC  that  will  be  embedded  in  the  development  process  through  discussions, 
peer  reviews,  and  validations  between  task  leaders  and  clinicians,  informatics  experts,  and  knowledge 
engineers.  We  will  also  establish  a  process  where  all  deliverables  will  be  reviewed  by  the  Principal 
Investigator  (PI)  and  the  QC  Manager  to  ensure  substantive  accuracy.  The  PI  and  Project  Manager  will 
also  provide  an  editorial  review  and  final  approval  of  all  deliverables  prior  to  submission  to  ensure  that 
they  are  well  written  and  conform  to  contractual  requirements  related  to  formatting  and  distribution. 

2.2.  Documentation  of  QC  Inspections:  The  quarterly  progress  reports  will  list  the  inspections 
performed  by  the  QC  Manager  by  date.  To  provide  more  timely  information,  the  inspections  will  be 
discussed  in  monthly  meetings  with  AHRQ.  These  discussions  will  include  the  results  of  product  reviews, 
problems  encountered,  and  changes  in  operating  procedures  to  address  problems. 

2.3.  Standard  Operating  Procedures  (SOP)  Document:  To  permit  others  to  replicate  the  work  that  will 
be  performed  on  this  project,  including  the  processes  used  to  set  up,  test,  and  produce  structured  logic — as 
well  as  the  processes  used  to  manage  the  project — we  will  assemble  an  SOP  document.  This  deliverable 
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will  include  descriptions  of  activities  and  the  underlying  rationale.  The  Project  Manager  and  task  leads 
will  be  responsible  for  documenting  activities  as  the  project  progresses. 

Task  3.  AHRQ  OCKT  Coordination 

Deliverables  that  will  be  made  publicly  available  (e.g.,  structured  logic  statements)  will  be  cleared 
through  the  AHRQ  Office  of  Communications  and  Knowledge  Transfer  (OCKT).  Thomson  Reuters  will 
work  with  OCKT  managers  and  editors  to  ensure  that  deliverables  meet  AHRQ  public  knowledge 
standards,  Web  content  and  508-compliance  standards,  AHRQ  and  departmental  clearance  processes, 
press  release  procedures  (if  applicable),  and  OCKT  timeframes.  The  project  team  will  coordinate 
communications  closely  with  OCKT  to  ensure  timely  releases.  OCKT  coordination  is  specified  in  the 
project  timeline,  although  OCKT  must  confirm  lead  times  needed  for  review  and  clearance. 

Task  4.  508  Compliance 

By  law,  all  electronic  and  information  technology  (EIT)  produced  by  or  on  behalf  of  a  federal  agency 
must  accommodate  persons  with  disabilities  by  providing  an  alternate  means  of  accessing  the 
information.  Thomson  Reuters  has  extensive  experience  producing  Web-based  deliverables,  software 
applications,  telecommunications,  video,  and  multimedia  to  meet  508  compliance  standards. 

4.1-4.2.  Draft  and  final  508  compliance  plan:  Thomson  Reuters  will  submit  a  compliance  plan  to 
ensure  that  public  deliverables  adhere  to  the  three  federal  regulations  specified  in  the  RFTO.  The  plan 
will  specify  the  deliverables  expected  to  be  released  through  the  Web  and  federal  requirements  that  must 
be  met.  After  receiving  feedback  from  AHRQ  on  the  draft  plan,  we  will  submit  a  final  plan  within  two 
weeks.  The  team  will  use  the  508  checklist  to  review  Web  content  before  delivering  it  to  OCKT. 

4,3.  Progress  on  508  compliance  plan:  As  noted  in  section  1.3,  quarterly  progress  reports  will  track 
compliance  with  508  requirements. 

Task  5.  Background  Assessment  and  Synthesis 

We  will  begin  this  task  by  working  with  AHRQ  to  identify  initiatives  to  review.  Our  team  is  currently 
engaged  in  a  number  of  relevant  ongoing  projects  and  will  bring  our  substantial  knowledge  of  the  field  to 
bear  on  this  task.  We  will  also  evaluate  the  guidelines  to  be  translated  and  lay  out  a  proposed  grouping  of 
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the  guidelines  for  processing.  The  RFTO  specifies  that  the  USPSTF  Grade  A  and  Grade  B 
recommendations  and  at  least  one  other  set  of  guidelines  be  chosen.  Thomson  Reuters  will  seek  input 
from  both  AHRQ  and  an  advisory  panel,  described  below,  to  facilitate  this  decision  making.  Next  we  will 
assess  advantages  and  disadvantages  of  relevant  formats,  tools  and  code  sets.  “Code  sets”  refer  to  the 
broad  range  of  relevant  taxonomies  and  ontologies,  ranging  from  health  standards  like  ICD-9,  ICD-10, 
CPT,  SNOMED  and  others,  to  the  more  CDS-specific  multi-faceted  clinical  ontologies.  “Formats”  refer 
to  structured  collections  of  information,  like  HL7,  Arden  syntax,  and  XML  variants  like  ArdenML.  Many 
“tools”  relevant  to  guideline  translation  have  been  produced  in  projects  including  GLIF,  GELLO, 
GEM/GLIDES,  the  CDS  Consortium,  the  Momingside  Initiative,  the  KMR  project,  and  Intermountain 
Healthcare  and  Partners  Healthcare  knowledge  management  efforts,  to  name  only  a  few.  Our  team  has 
played  major  roles  in  several  of  these  efforts. 

Our  team  will  evaluate  guideline  translation  resources  and  approaches  by  tapping  into  users’  experiences 
(using  listservs  to  communicate  with  the  memberships  of  relevant  organizations  such  as  AMIA,  the 
Association  of  Medical  Directors  of  Information  Systems  (AMDIS),  Scottsdale  Institute,  and  HIMSS),  by 
reviewing  the  contents  of  AHRQ’s  HIT  portfolio,  by  identifying  and  evaluating  relevant  literature,  and  by 
drawing  on  the  informatics  experts  on  our  own  team  and  their  extensive  international  network  of  contacts. 
We  will  also  leverage  existing  tools  to  help  facilitate  project  coordination  and  knowledge  management, 
including  Alfresco  (a  publicly  available  content  management  system)  and  Protege  (a  free,  open  source 
ontology  editor  and  knowledge-base  framework). 

Based  on  our  review  of  these  materials,  input  from  AHRQ  and  the  broad  group  of  stakeholders  we  have 
identified  (see  Task  6),  we  will  draft  a  report  that  documents  our  assessment  and  lays  out  a  process  for 
producing  structured  logic  statements  that  address  real  world  implementation  challenges.  After  receiving 
feedback  from  AIIRQ  we  will  revise  and  submit  our  final  Task  5  report. 

Task  6.  CDS  GC  Meetings 

This  task  consists  of  two  main  components.  The  first  is  interaction  with  the  Clinical  Decision  Support 
Government  Collaboratory  (CDS  GC).  The  second,  which  we  have  added,  is  establishing  and  using  a 
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“Rule  Value  Advisory  Panel  (RVAP).” 

The  CDS  GC  was  formed  in  March,  2008  and  is  sponsored  by  AHRQ,  ONC,  and  HHS.  The  CDS  GC  is 
an  important  collaboration  of  federal  experts  and  stakeholders  who  will  review  deliverables  and  processes 
developed  by  this  project.  As  directed  by  the  TOO,  the  Thomson  Reuters  team  will  attend  the  CDS  GC 
quarterly  meetings  in  the  Washington,  DC  area.  The  PI  and  DC-based  Management  Advisor  will  attend 
these  in  person;  other  required  personnel  will  attend  one  meeting  in  person  and  others  by  phone — we  plan 
to  scheduled  an  in-person  team  production  process  planning  and  review  meeting  with  AHRQ  to  coincide 
with  a  planned  CDS  GC  meeting.  Team  members  will  present  progress  and  describe  any  identified 
challenges  related  to  developing  hardened  rules  for  CDS  implementation.  We  will  use  this  opportunity  to 
learn  from  the  experiences  and  needs  the  federal  experts  have  around  all  phases  of  guideline  translation — 
from  development  and  dissemination  to  uptake  and  value  delivery.  Following  CDS  GC  meetings,  we  will 
prepare  a  summary  of  the  key  insights  obtained  from  and  shared  with  the  CDS  GC. 

The  second  effort  under  Task  6  is  the  establishment  of  a  Rule  Value  Advisory  Panel,  or  “RVAP.”  The 
RVAP  will  help  ensure  that  the  work  of  this  Task  Order  is  supported  by  the  full  range  of  perspectives  and 
stakeholders  required  for  success.  These  parties  include  guideline  developers  and  implemented, 
information  system  providers  and  users,  informatics  experts  in  the  full  range  of  CDS  development  and 
implementation  issues,  and  entities  addressing  performance  measurement  and  reporting.  The  RVAP  will 
augment  the  substantial  expertise  of  the  core  team  in  many  of  the  pertinent  domains.  It  will  be  comprised 
of  up  to  20  additional  stakeholders  and  experts  who  will  interact  through  listserv  communications  and  two 
formal  teleconferences.  To  engage  participants,  we  will  leverage  the  core  team’s  expertise  and  experience 
with  key  constituencies,  as  well  as  AMIA’s  extensive  network  of  contacts.  Several  individuals  and 
organizations  have  already  expressed  willingness  to  participate.  AMIA  will  coordinate,  plan  for,  and 
structure  the  RVAP  meetings  and  support  the  development  of  work  products  and  materials  for  the  Panel’s 
review.  Dr.  Ted  Shortliffe  will  serve  as  the  RVAP  Chair  and  lead  the  two  advisory  panel  teleconferences. 
The  advisory  work  of  the  RVAP  will  be  augmented  by  listserv  communications  with  members  of 
pertinent  groups  such  as  AMDIS  and  the  AMIA  Clinical  Information  Systems  Workgroup. 
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Table  2  below  provides  examples  of  key  stakeholder  candidates  for  RVAP  participation.  We  have 
initiated  efforts  to  identify  appropriate  subject  matter  experts,  as  well  as  those  with  experience  working  on 
relevant  aspects  of  CDS  development,  deployment,  and  value  realization. 

Included  in  the  RVAP  are  representatives  of  two  key  constituencies:  EHR  vendors,  represented  by  the 
HIMSS  Electronic  Health  Record  Association  (EHRA),  and  EHR/CDS  implementers  represented  by 
AMDIS  (see  letters  of  support  in  Appendix  B).  EHRA  is  the  leading  association  of  EHR  vendors  and 
their  participation  will  help  ensure  that  our  final  deliverables  can  be  implemented  in  their  members’ 
systems.  AMDIS  is  the  leading  professional  organization  for  physicians  interested  in  and  responsible  for 
healthcare  information  technology.  Their  involvement  will  engage  those  who  lead  the  deployment  of 
clinical  information  systems  (including  CDS  rules)  in  many  of  the  nation’s  health  systems,  thereby 
helping  to  ensure  widespread  rule  adoption. 

Table  2.  Key  Stakeholder  Candidates  for  RVAP  Collaboration 


Guideline  developers 

USPSTF,  ACIP,  NIH  (e.g.,  NHLBI),  med.  specialty  societies 

CIS  vendors  and  implementers 

EHRA,  IHE,  HIMSS 

Informatics  experts 

AMIA,  ACMI,  AMIA  Academic  Forum,  NLM  fellowship 
programs,  CDC  Centers  of  Excellence 

Coding/standards  experts 

NCHS  and  CMS  (ICD-10);  AM  A  (CPT);  NLM  (SNOMED), 
LOINC,  CDISC,  HL7,  IIITSP,  HITSC 

Performance  improvement 
/outcome/measurement  experts 

NQF,  NCQA,  JCAHO,  CMS,  IHI,  HEDIS,  pay  for  performance 
efforts  (such  as  Leapfrog) 

Other  essential  stakeholders  TBD 

Providers  (hospitals,  clinics,  etc.);  Federal  stakeholders  (Armed 
Services);  Indian  Health  Services,  HRSA,  NIH,  FDA; 

SAMHSA,  payers  (AHIP,  BCBSA),  philanthropies  (RWJF, 
Commonwealth  etc),  VA,  community  health  centers,  NGA 
(National  Governors  Association),  NIST,  ARP,  Business 

Groups  on  Health,  AFL-CIO,  AHA,  Cochrane,  ECRI 

Task  7.  Create  structured  coded  logic  statements  for  selected  guidelines 

Our  proposal  for  developing  a  rules  repository  begins  with  the  end  objective  in  mind.  We  want  effective, 
widely  deployable  rules  that  will  drive  measurable  performance  improvement.  To  achieve  this  goal,  we 
will  create  an  efficient  process  for  developing  rules  that  can  be  iteratively  refined,  increasingly  automated, 
and  readily  scaled.  Once  we  have  created  such  a  process,  we  will  use  it  to  produce  rules  reflecting 
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USPSTF  Grade  A  and  Grade  B  recommendations,  and  at  least  one  other  guideline.  Based  on  the 
evaluation  of  guidelines,  formats,  codes  sets  and  tools  performed  in  Task  5,  we  will  propose  a  production 
plan  for  guideline  translation,  as  well  as  an  order  in  which  to  transform  the  guidelines.  We  anticipate  that 
our  plan  for  production  will  resemble  that  outlined  in  the  first  three  stages  in  Figure  2  below. 

Figure  2.  Proposed  Stages  of  Rule  Development  and  Production  Lifecycle 


Stages  of  Rule  Development  Production  Process 


f - ' 

1.  Free-text  logic 
statement 

_ u 

Assemble  Knowledge 

•  Assemble  elements  of  narrative  guideline  needed  to  produce  a 
logical  statement 

•  Include  other  CDS-related  elements 

r  7 

2.  Structured  logic 
statement 

*  j 

Create  Structured  Logic  Statement 

•  Express  medical  knowledge  in  structured  format  that  codifies  data 
and  logical  expressions 

•  Flag  and  annotate  items  that  require  further  disambiguation 

r  7 

3.  Pre-executable 
logic  statement 

L  J 

Translate  Statement  to  Pre-executable  Format 

•  Evaluate  logic  statements  in  use  scenarios 

•  Incorporate  attributes  that  anticipate  local  implementation 
considerations,  data  types  and  rule  triggering  scenarios 

r  > 

4.  Deployable  logic 
statement 

(out  cf  TO  s:ops| 

v  J 

Generate  Deployable  Rules 

•  Develop  setting-specific  representations  for  local  systems 

•  Ensure  the  rule  can  be  engineered  into  HIS  and  care  setting 

To  move  the  rules  through  this  production  process,  we  will  use  a  series  of  templates.  Controlled 
vocabularies  will  be  used  for  some  template  fields  and  meta-tags,  and  for  all  content  data  elements.  In 
Stages  2  and  3,  the  reference  patient  data  model  will  likely  be  the  HL7  Clinical  Statements  model  used  in 
the  Continuity  of  Care  Document  (CCD)  specification.  Our  working  assumption  is  that  clinical 
terminology  will,  whenever  possible,  be  specified  in  SNOMED-CT. 

Because  the  stages  shown  in  Figure  2  have  never  been  fully  integrated  and  executed  in  a  scalable  fashion, 
we  will  refine  the  approach  as  we  discover  how  best  to  structure  the  process  and  create  the  rules  in  a 
manner  that  will  support  widespread  adoption.  As  we  begin  producing  the  first  batch  of  rules,  we  will 
select  one  recommendation  to  move  (conceptually)  through  the  entire  development  lifecycle  to 
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understand  the  complexities  potential  implemented  will  confront  in  embedding  the  rule  in  a  production 
system.  While  we  are  not  proposing  to  translate  guidelines  through  Stage  4,  that  is,  into  a  format  directly 
suitable  for  implementation  in  a  given  setting  and  clinical  information  system,  our  production  plan  will 
move  one  guideline  conceptually  into  Stage  4  to  help  ensure  that  the  Stage  3  rules  we  produce  can  be 
readily  deployed  into  production  systems.  Once  the  selected  guideline  has  been  moved  through  Stage  3,  a 
CDS  implementer  (Johns  Hopkins)  will  review  the  final  rule  in  terms  of  its  ability  to  be  integrated  into 
their  information  systems.  They  will  evaluate  the  rule’s  triggering  process,  its  ability  to  be  integrated  into 
practice  workflow,  and  the  usefulness  of  the  representation  for  direct  interpretation  or  conversion  into  a 
form  that  can  be  directly  interpreted  or  executed.  AMDIS  members  will  conduct  similar,  though  less 
formal,  assessments.  This  evaluation  will  constitute  the  “conceptual”  Stage  4  implementation. 

After  the  implemented’  critique,  we  will  hold  the  first  teleconference  with  the  RVAP  to  review  the 
results  and  refine  the  production  process.  This  test  and  review  approach  will  influence  the  format  and 
content  of  the  final  deliverable  to  ensure  that  it  will  achieve  the  goals  of  widespread  deployment  and 
usefulness.  In  addition,  regular  interactions  with  the  CDS  GC  will  provide  federal  perspective  on  how 
hardened  rules  can  be  developed  and  deployed  in  HIT  systems  to  align  care  with  strong  clinical  evidence. 
The  production  of  the  logic  statements,  which  will  be  available  for  uptake  by  the  implementer  and  HIT 
vendor  communities,  will  occur  in  batches  to  allow  for  further  refinement  of  the  process,  phased 
production,  and  review  of  the  rules  by  AHRQ.  We  will  propose  priorities  for  rule  production,  grouping 
guidelines  into  batches  based  on  their  suitability  for  full  implementation  in  clinical  systems  (e.g.,  Group  1 
might  include  guidelines  for  which  rule  triggering  and  evaluation  data  can  be  readily  obtained  in  existing 
clinical  systems  and  for  which  workflows  are  straightforward.  When  production  of  the  first  guideline 
batch  has  been  completed,  we  will  reconvene  the  RVAP  to  review  the  process  and  the  results,  and  then 
make  any  necessary  changes.  As  we  gain  experience,  we  will  encode  additional  rules  that  raise  greater 
translation  and  implementation  challenges.  An  outline  of  each  stage  of  the  production  pipeline  follows; 
proposed  details  would  be  enhanced  based  on  Task  5  results. 

Stage  1:  Assemble  Knowledge.  Clinical  experts  will  assemble  the  actionable  elements  of  the  narrative 
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guideline  that  are  needed  to  produce  a  free  text  logic  statement  and  any  necessary  annotation.  The 
resulting  logic  statement  will  outline  the  recommendation  in  a  manner  appropriate  for  eventual  execution 
as  a  CDS  intervention.  That  is,  it  will  lay  out  all  of  the  components  within  the  recommendation  that  are 
pertinent  to  creating  an  ‘if. .  .then. .  .else. . .”  statement  that  can  be  executed  within  a  clinical  information 
system.  These  include  descriptions  of  what  should  be  done,  to  whom  it  should  be  done,  when  it  should  be 
done,  how  often  it  should  be  done,  and  any  reasons  it  should  not  be  done.  The  quantities  and  types  of 
pertinent  elements  may  differ  with  each  type  of  guideline  or  recommendation  (e.g.,  those  for  screening 
tests  for  early  detection  may  vary  from  those  for  drug  treatment).  At  this  stage  we  will  simply  collect  all 
these  pertinent  characteristics  and  organize  them  in  a  template  for  further  analysis. 

Stage  2:  Create  Structured  Logic  Statements.  In  Stage  2,  the  free  text  statement  will  be  expressed  in  a 
structured  format  that  organizes  the  medical  logic  and  data  contained  in  the  statement.  We  will  also  tag 
and  structure  other  components  and  apply  meta-tags  to  categorize  each  element.  For  example,  elements 
pertaining  to  eligibility  criteria,  recommended  actions,  or  care  setting  will  be  identified  as  such.  During 
this  stage,  any  ambiguities  in  the  free-text  statement  that  need  to  be  specified  before  implementation  will 
be  annotated  in  the  rule  markup.  The  meta-tags  will  be  drawn  from  the  GEM1 '  schema  for  narrative 
markup,  and  others  we  have  identified  as  valuable  for  characterizing  workflow  and  clinical  context 
attributes.  XML  authoring  tools  will  support  meta-tag  management.  Our  team  has  particular  experience  in 
developing  XML-oriented  forms  with  Altova  Corp’s  XMLSpy  and  StyleVision  tools,  and  we  plan  to  use 
this  tool  suite  for  forms  design  and  meta-tagging.  We  are  also  tracking  development  of  open  source  CDS 
authoring/editing  tools  in  projects  with  which  our  team  members  are  involved,  including  the  Momingside 
Initiative  and  the  KMR  project,  and  will  leverage  those  as  appropriate. 

Stage  3:  Produce  Formal  Logic  Statements.  During  Stage  3,  the  structured  logical  statement  will  be 
translated  into  a  pre-executable  format  using  ArdenML,14  a  meta-level  formalism  that  can  subsequently 

13  Shiftman  R,  Karras  B,  Agrawal  A,  Chen  R,  Marenco  L,  Nath  S.  GEM:  A  proposal  for  a  more  comprehensive 
guideline  document  model  using  XML.  J  Am  Med  Inform  Assoc.  2000;  7:488^498. 

14  Kim  S,  Haug  PJ,  Rocha  RA.  Choi  I.  Modeling  the  Arden  Syntax  for  medical  decisions  in  XML.  Ini  J  Med  Inform. 
2008  Oct;  77(10):650-6. 
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generate  Arden  Syntax  MLMs  or  other  output  formats.  At  this  point,  local  implementation  considerations 
will  be  taken  into  account,  as  will  rule  triggering  scenarios.  The  data  types  and  corresponding  codes  that 
will  be  needed  to  gather  data  to  trigger  rules  and  evaluate  logic — and  to  enable  rule  actions  via 
appropriate  channels — will  be  identified.  Methods  for  triggering  the  rule  also  will  be  formulated.  Because 
of  the  various  potential  rule  triggers — such  as  actions  based  on  internal  clocks,  on  patient  encounters,  and 
on  automated  review  of  patient  records — Stage  3  output  might  present  the  potential  user  (a  rule 
implementer)  the  opportunity  to  pick  the  alternative  best  suited  to  the  local  environment. 

Stage  4:  Conceptually  Implement  in  Specific  Setting(s).  The  final  stage  of  the  first-pass  rule  lifecycle 
is  beyond  the  scope  of  this  Task  Order.  Nonetheless,  because  anticipating  local  implementation  is  critical 
to  ensuring  optimal  value  from  project  deliverables,  we  include  it  in  the  lifecycle  diagram,  and  address  it 
by  conceptually  developing  and  vetting  output  at  this  stage,  as  outlined  above.  Fully  addressing  this  stage 
requires  engineering  the  rule  into  a  specific  clinical  information  system  and  care  setting,  a  task  which 
would  involve  adapting  rule  parameters  to  local  clinical  policies,  and  then  either  encoding  the  rule  in  the 
host  rule-evaluation  language  or  embedding  it  in  a  service-oriented  architecture  (SOA)-based  module.  By 
using  Arden  ML  in  Stage  3,  translation  into  a  SOA-based  module  can  be  semi-automated. 

Task  8.  Final  Report 

8.1.  Draft  and  Final  Report:  Thomson  Reuters  will  develop  a  final  project  report  that  includes  1)  project 
purpose  and  background,  2)  intended  audiences,  3)  methods  and  processes  used  to  accomplish  the  project, 
4)  a  summary  of  key  deliverables,  5)  advice  for  other  guideline  translation  efforts,  and  6)  other  lessons 
learned  from  the  rule  development  process.  Appendices  will  include  templates  and  checklists  useful  for 
other  guideline  translation  projects.  The  report  will  be  designed  for  Web  dissemination  with  a  PDF 
version  for  print  distribution.  It  will  include  an  executive  summary,  a  hyperlinked  table  of  contents,  main 
text,  and  appendices.  The  plan  for  the  final  report  will  be  specified  in  the  Project  Plan  of  Task  1. 

C.  Personnel 

The  strength  of  the  Thomson  Reuters  team  lies  in  our  diverse  perspectives  and  deep  expertise  in  clinical 
decision  support,  as  well  as  in  our  shared  sense  of  an  effective  approach  to  accomplishing  the 
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requirements  of  this  Task  Order.  In  addition  to  the  expertise  Thomson  Reuters  offers,  our  team  includes 
subcontractors  from  AMIA,  Arizona  State  University  (ASU),  Intermountain  Healthcare  (IHC),  Johns 
Hopkins  University  (JHU),  and  the  University  of  California  at  San  Diego  (UCSD).  Leaders  of  the  project 
are  specified  in  the  Organizational  Chart  below  (Exhibit  1 )  and  their  education  and  experience  is 
individually  described  in  the  CVs  provided  in  Appendix  A. 


Exhibit  1.  Organizational  Chart 


*  Advisory  Panels:  EHRA:  Electronic  Health  Record  Association,  AMDIS:  Association  of  Medical 
Directors  of  Information  Systems.  RVAP:  Rule  Value  Advisory  Panel 
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The  proposed  project  team  includes: 

•  Thomson  Reuters,  providing  leadership  on  leveraging  CDS  to  improve  care  process  and  outcomes 
and  on  overall  project  design  (by  Jerome  Osheroff,  MD,  Principal  Investigator);  management 
direction  to  staff  and  technical  contributors  (by  Andriana  Hohlbauch,  MPH);  senior-level  quality 
control  (by  Rosanna  Coffey,  PhD  in  Economics);  and  strong  task  leadership  for  synthesis, 
deliverables,  and  dissemination  (by  Susan  Raetzman,  MSPH). 

•  American  Medical  Informatics  Association,  providing  connectivity  to  nationally  and 
internationally  renowned  expertise  in  biomedical  and  health  informatics;  leadership  for  the  Rule 
Value  Assurance  function,  including  chairmanship  of  the  proposed  RVAP  and  collaboration  on 
project  design  (by  Ted  Shortliffe,  MD,  CEO);  and  management  of  the  RVAP  and  liaison  with  EHR 
vendors  and  implementers  through  the  HIMSS  Electronic  Health  Records  Association  (EHRA)  and 
the  AMDIS  (by  Meryl  Bloomrosen). 

•  Experts  that  will  lead  the  Guideline  Translation  task  and  its  subtasks.  These  are  clinicians  and  PhDs 
who  understand  the  clinical  decision-making  process  firsthand  and  who  are  professionally  recognized 
for  their  pioneering  and  foundational  accomplishments  in  designing  and  operating  CDS  systems, 
particularly  in  terms  of  the  highly  technical  and  specialized  area  of  rule  specification,  translation,  and 
implementation.  The  experts  include: 

o  Robert  Greenes,  MD,  PhD,  as  the  proposed  Task  Lead  for  Guideline  Translation  overall  and  as 
Subtask  Lead  for  Batch  Production,  has  long  experience  and  expertise  in  clinical  decision  making, 
knowledge  representation,  knowledge  management,  and  in  individualized  context-specific  decision 
support.  In  addition,  Margarita  Sordo,  MSc,  PhD,  who  has  over  10  years  of  experience  applying 
artificial  intelligence  and  knowledge  elicitation  and  formalization  techniques  in  various  areas  of 
healthcare,  will  be  instrumental  in  supporting  the  batch  production  function, 
o  Aziz  Boxwala,  MD,  PhD,  as  Subtask  Lead  for  Production  Set  Up,  is  a  seasoned  developer  and 
translator  of  clinical  guidelines  who  is  currently  working  with  AHRQ  on  related  projects.  Also 
contributing  to  tins  function  will  be  Diana  Petitti,  MD,  MPH  Vice-Chair  of  the  USPSTF. 
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o  Peter  Haug,  MD,  as  Subtask  Lead  for  Production  Testing,  will  bring  to  this  project  his  practical 
experience  in  developing  components  of  medical  information  systems  and  innovative  tools  for 
implementing  decision  support  in  active  clinical  settings  such  as  Intermountain  Healthcare, 
o  Douglas  Fridsma,  MD,  PhD,  as  Subtask  Lead  for  Technical  Evaluation,  will  bring  to  this  project 
his  technical  expertise  in  semantic  interoperability  and  systems  architectures  and  his  collaborative 
experiences  in  testing  CDS  implementation. 

D.  Management  Plan,  Capability',  and  Past  Performance 

To  succeed,  this  project  requires  collaboration  from  specialized  experts  in  the  many  facets  of  guideline 
translation  and  from  many  stakeholders  in  the  end  product,  making  the  management  plan  critical.  This 
section  addresses  key  management  plan  components  and  includes  information  on  our  corporate 
experience,  selection  of  team  members,  and  our  management  tools  and  systems. 

Management  Plan.  The  required  expertise  in  guideline  translation  and  execution  demands  that  our 
project  team  have  broad  and  deep  expertise  in  CDS.  In  addition  to  proposing  to  subcontract  with  five 
organizations  and  one  consultant,  we  have  identified  organizations  willing  to  provide  in-kind  support  and 
other  experts  who  are  interested  in  participating  in  the  RVAP.  To  manage  such  a  large  and  diverse  team 
of  stakeholders,  and  to  ensure  that  project  deliverables  and  objectives  meet  AHRQ’s  intentions,  we  will 
establish  management  systems  that  include:  clear  organizational  structure  directing  lines  of  authority  and 
avenues  of  communication,  a  staffing  plan  by  task,  a  timeline  with  detailed  deliverable  and  work  review 
schedules,  structured  budget  and  accounting  processes  with  customized  reporting  capability,  quality 
control  processes  (described  in  section  B),  and  standard  progress  reports  and  status  meetings  with  AHRQ 
and  with  our  subcontractors. 

Capabilities  and  Team  Selection.  Thomson  Reuters  has  assembled  a  strong  team  of  experienced 
professionals  for  this  task  order.  Our  proposed  PI  has  led  highly  successful  and  influential  collaborative 
efforts  around  CDS  research  and  development,  implementation  best  practices,  and  policy.  The  Project 
Manager  has  a  track  record  of  effective  day-to-day  management  of  large,  high-visibility  initiatives  such  as 
CMS’s  Medical  Home  demonstration,  and  the  Quality  Control  manager  has  a  career-long  reputation  as  a 
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strong  government  contracts  liaison.  Other  members  of  our  team  include  leading  stakeholders  with 
extensive  expertise  in  clinical  informatics,  excellence  in  care  delivery,  EHR  systems,  and  technical  rule 
translation.  More  detailed  capabilities  are  available  in  the  CVs  provided  in  Appendix  A. 

Table  3  below  provides  staff  allocations  by  task  and  the  percent  availability  for  all  team  members. 

Table  3.  Staff  Percent  Dedicated  Time  to  Project 


RFTO  #4  Proposal  under  AltRQ  HIT  IDIQ  #HHSA 
2902009000221  -  “Hardened  Rules  for  Clinical  Decision 
Support” 

Total 

% 

Proposed 

% 

Availability 

Task  1: 

Administra¬ 

tion 

Task  2: 
Quality- 
Control 
&  Std  Opg 
Procedures 
(SOP) 

Task  3:  OCKT 
Coordination 

Task  4:  508 
Compliance 
Plan 

Year  1  -  Hours  by  Task 

mmm 

Coffey,  R. 

54 

3% 

15% 

2 

20 

- 

- 

Hotel,  K. 

64 

3% 

50% 

26 

8 

4 

4 

Hohlbauch,  A. 

232 

12% 

30% 

168 

30 

4 

4 

Mummert,  A. 

24 

1% 

20% 

- 

- 

- 

24 

Osheroff,  J. 

192 

10% 

15% 

26 

26 

- 

- 

Raetzinan,  S. 

152 

8% 

25% 

56 

16 

- 

- 

Seawards,  J. 

40 

2% 

10% 

- 

- 

- 

- 

Stranges,  E. 

256 

13% 

30% 

26 

24 

30 

- 

Consultant  -  Sorda,  M. 

225 

12% 

- 

- 

- 

Subcontractor  -  AMIA  support 

391 

20% 

25% 

85 

18 

24 

- 

Subcontractor  -Arizona  State  University 

614 

32% 

35% 

68 

12 

► 

- 

Subcontractor  -  Intermounlain  Healthcare  Services,  Inc. 

852 

44% 

75% 

4 

- 

- 

- 

Subcontractor  -  Johns  Hopkins  University 

56 

3% 

10% 

- 

- 

- 

- 

Subcontractor  -  University  of  California  San  Diego 

154 

8% 

10% 

- 

• 

- 

- 

EMM 

461 

154 

62 

32 

Past  Performance.  As  outlined  above,  the  team  has  led  many  of  the  enabling  initiatives  related  to  CDS 
rule  development  and  dissemination.  Corporate  qualifications  of  Thomson  Reuters,  Johns  Hopkins 
University,  and  AMIA  regarding  the  creation  of  successful  collaborative  relationships  and  demonstrably 
valuable  CDS  resources  are  outlined  in  the  original  IDIQ  proposal.  Following  are  key  examples  of 
relevant  team  member  experiences  related  to  translating  clinical  recommendations  into  system-integrated 
formats  and  developing  clinical  guidelines. 

•  An  inventory  study  at  Partners  Healthcare  (Greenes,  Boxwala)  that  involved  examining  all  rules- 
based  knowledge  in  the  various  IT  applications,  their  different  representations,  editing  approaches, 
and  delivery  modes,  and  synthesizing  these  results  to  propose  a  rules  engine  approach  (Greenes, 
Sordo)  to  CDS  delivery.  The  model  identified  a  small  set  of  predicate  classes  that  comprised  all  of  the 
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hundreds  of  rules,  a  modest  set  of  data  object  type  references,  and  a  limited  set  of  action  types  that 
could  lend  themselves  to  more  structured  representation  and  template-  or  wizard-based  authoring. 

•  Creation  of  specification  for  GELLO  expression  language  (Greenes,  Sordo,  Boxwala),  work  on  GLIF 
(Greenes,  Boxwala),  and  a  hierarchical  intention-based  refinement  of  the  GLIF  guideline  model 
(Boxwala,  Greenes).  Establish  GELLO  as  a  standard  (Greenes,  co-chair  of  HL7  CDS  Technical 
Committee)  and  adoption  of  the  Virtual  Medical  Record  (VMR)  model  as  a  proposed  standard. 

•  Major  contributions  to  the  development  of  the  BRIDG  model  for  protocol-driven  medical  research 
(Fridsma),  supported  by  CD1SC  and  HL7.  Development  of  an  XML-based  model  for  interchangeable 
CDS  based  on  the  Arden  Syntax  known  as  Arden  ML  (Haug),  which  has  a  higher  degree  of  semantic 
interoperability.  Promotion  of  Arden  ML  consideration  in  HL7  as  a  next-generation  standard. 

•  Participation  in  the  Momingside  Initiative  (Greenes,  Fridsma,  Haug),  a  consortium  of  institutions 
developing  approaches  to  knowledge  sharing  for  clinical  decision  support,  and  in  the  KMR  project  of 
the  Department  of  Defense  (Fridsma).  The  KMR  project  involves  developing  a  platform  for  open 
source  authoring/editing  and  deploying  CDS,  initially  focused  on  the  AHLTA  environment.  The  ASU 
Department  of  Biomedical  Informatics  also  runs  the  Clinical  Application,  Research,  and  Education 
Interoperability  Testbed  (CARE-IT)  Consortium  (Fridsma)  focusing  on  developing  and  testing 
interoperable  health  care  information  technology  resources. 
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Project  Timing.  The  Gantt  chart  below  provides  an  overview  of  planned  project  tasks  and  deliverables  by  calendar  month. 

Exhibit  2.  Project  Timeline  and  High  level  Deliverables 
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A  Model  for  Sharing  Knowledge  and  Tools  for  Clinical  Decision  Support 
Driven  by  a  Use  Case  Requiring  Interoperable  Delivery  in  the  AHLTA 
Environment:  A  Collaborative  Partnership  of  the  Morningside  Initiative  with 

the  Department  of  Defense 

Douglas  B.  Fridsma,  MD,  PhD1,  Emory  Fry,  MD2,  Peter  J  Haug,  MD3;  Mary  Goldstein, 

MD,  MSc4,  Robert  A.  Greenes,  MD,  PhD1 

'Arizona  State  University,  Phoenix,  A Z; 

2Naval  Health  Research  Center,  San  Diego,  CA 
’intermountain  Healthcare  System,  Salt  Lake  City,  UT 
4VA  Palo  Alto  Health  Care  System,  Palo  Alto,  CA 


Abstract 

Many  organizations  have  developed  clinical  decision 
support  (CDS)  content,  but  sharing  of  the  work 
among  different  organizations  has  been  limited. 
Several  groups  are  exploring  the  many  reasons  for 
these  collaborative  difficulties,  The  Morningside 
Initiative  is  a  public-private  partnership  to  develop  a 
model  for  generalizing,  sharing,  and  reusing  best 
available  clinical  decision  support  content.  The 
Knowledge  Management  Repository’  (KMR)  project  a 
research  program  sponsored  by  the  Department  of 
Defense  seeking  to  develop  the  infrastructure 
required  for  the  Military  Health  System  to  accept  and 
execute  computable  guidelines  within  its  runtime 
environment. 

This  panel  describes  a  unique  collaboration  between 
the  Morningside  Initiative  and  the  KMR  project  to 
combine  their  initiatives  to  jointly  detennine  the 
functional  requirements  developing  interoperable 
CDS  capabilities.  We  describe  the  current 
implementation,  its  relationship  to  the  National 
Health  Information  Network  (NHIN)  infrastructure, 
and  the  goal  of  demonstrating  a  functional  prototype 
using  the  Department  of  Defense  clinical  data 
repository  and  bedside  client. 

Introduction 

In  August,  2007,  a  workshop  sponsored  by  the 
Telemedicine  and  Advance  Research  Center 
(TATRC)  at  the  Morningside  Inn  in  Frederick,  MD, 
addressed  the  prospect  of  stimulating  approaches  to 
shared  knowledge  management  for  clinical  decision 
support  (CDS).  The  workshop  was  moderated  by  Dr. 
Robert  Greenes  M.D.,  Ph.D.,  and  attended  by 
representatives  from  the  DoD,  including  the  Veterans 
Health  Administration  (VHA),  Department  of 
Defense  (DoD),  Kaiser  Permanente,  Partners 
Healthcare  and  Henry  Ford  Healthcare  System,  the 


American  Medical  Informatics  Association  (AMIA), 
Office  of  the  National  Coordinator  for  Health 
Information  Technology  (ONC),  the  Agency  for 
Healthcare  Research  and  Quality  (AHRQ)  and 
TATRC.  The  consensus  of  the  participants  was  that 
an  open  source,  open  standard,  vendor-agnostic 
infrastructure  would  enable  organizations  to  work 
together  to  develop  and  exchange  clinical  content, 
technology,  tools  and  processes  in  applied  CDS.  The 
system  could  improve  quality  of  care  through 
technology  such  as  reminders,  alerts,  guidelines,  and 
order  sets.  It  would  decrease  development  time  and 
the  costs  of  enterprise-specific  knowledge 
management  efforts.  The  participants  established  the 
Morningside  Initiative  to  pursue  this  vision, 
subsequently  adding  Intermountain  Health  and 
Arizona  State  University  as  collaborators. 

Concurrently,  the  DoD  was  investigating  the 
operational  execution  of  clinical  practice  guidelines 
within  the  military  health  system  It  project  sought  to 
augment  and  refocus  existing  information  technology 
capabilities  within  the  agency  on  the  functional 
requirements  for  a  Knowledge  Management 
Repository  (KMR)  and  Clinical  Decision  Support 
Engine..  This  project  was  leveraging  its  Service 
Oriented  Architecture  approach  to  the  Nationwide 
Health  Information  Network  (NHIN)  teclinology  to 
address  the  needs  of  the  broader  clinical  decision 
support  community. 

Recognizing  a  unique  opportunity,  project  leaders  for 
both  the  Morningside  Initiative  and  the  KMR  project 
established  a  unique  partnership  and  now  collaborate 
in  clinical  decision  support  and  content  management 
research.  The  KMR  project  provides  a  tactical 
platform  for  interoperable  delivery  and  local 
management  of  domain  knowledge,  while  the 
Morningside  Initiative  contributes  its  considerable 
research  and  academic  expertise  to  the  defining  the 
functional  requirements  for  knowledge  acquisition 


analysis,  representation,  and  management  for  site- 
specific  execution. 

Panel  Topics  and  Structure 

(Fridsma)  Moderator  and  framing  of  purpose  of 
panel 

(Greenes)  Review  of  prior  and  ongoing  collaborative 
projects  related  to  CDS,  and  unique  aspects  of  the 
Momingside-K.MR  collaboration. 

(Haug)  Describe  the  development  of  functional 
requirements  and  models  to  support  a  standard 
format  for  representing  CDS  knowledge.  This  will 
address  the  separation  of  the  business/operations 
knowledge  from  the  clinical  knowledge,  and  provide 
insight  into  how  CDS  rules,  drawn  from  different 
organizations  can  be  normalized  and  placed  in  a 
common  repository. 

(Goldstein)  Translating  clinical  knowledge 
embedded  in  computable  formats  for  one  health  care 
system’s  electronic  record  to  standardized  format  for 
sharing  with  other  systems.  This  presentation  will 
illustrate  issues  that  arise  in  this  translation  and  the 
insights  gained  from  translating  several  different 
reminders  and  other  fragments  of  clinical  knowledge. 

(Fry)  The  Federal  CDS  implementation  in  the 
context  of  AHLTA  and  the  NHIN  .  This  presentation 
will  describe  the  NHIN  adapter  in  more  detail  and 
how  the  CDS  systems  developed  in  the  KMR  project 
and  the  work  of  the  Momingside  Initiative  will  be 
used  to  deliver  CDS  within  the  NHIN  infrastructure. 

Panel  Participants 

Douglas  B  Fridsma,  MD  PhD 

Associate  Professor,  Department  of  Biomedical 
Informatics,  Arizona  State  University,  Arizona 
Biomedical  Collaborative,  425  N.  5th  St.,  Phoenix, 
AZ  85004-2157,  Tel:  602-827-2515,  Email: 
fridsma@asu.edu 

Robert  A.  Greenes,  MD,  PhD 

Ira  A.  Fulton  Chair  and  Professor,  Department  of 
Biomedical  Informatics,  Arizona  State  University, 
Arizona  Biomedical  Collaborative,  425  N.  5th  St., 
Phoenix,  AZ  85004-2157,  Tel:  602-827-2548, 
Email:  greenes@asu.edu 

Mary  K.  Goldstein  M.D.,  MSc 

Professor  of  Medicine  in  the  Center  for  Primary  Care 
and  Outcomes  Research  and  of  Health  Research  and 
Policy  (by  courtesy),  Stanford  University  School  of 
Medicine,  and  Director,  Geriatrics  Research 


Education  and  Clinical  Center  (GRECC),  VA  Palo 
Alto  Health  Care  System,  Geriatrics  Research 
Education  &  Clinical  Center  (GRECC)  182-B,  3801 
Miranda  Avenue,  Palo  Alto,  CA  94304  email: 
Mary.Goldstein@va.gov 

Peter  Haug,  MD 

Director,  Homer  Warner  Center  for  Informatics 
Research  at  Intermountain  Healthcare  and  Professor, 
Department  of  Biomedical  Informatics  at  the 
University  of  Utah.  Salt  Lake  City,  Utah.  Email: 
Peter.Haug@imail.org 

Emory  Fry,  MD 

Assistant  Professor  of  Pediatrics,  Uniformed  Services 
University  for  Health  Sciences,  Neonatologist,  Naval 
Medical  Center,  San  Diego  and  informatics 
researcher.  Naval  Health  Research  Center,  San 
Diego,  CA.  email:  emory.fry@med.navy.mil 

All  panel  participants  have  agreed  to  take  part  on  the 
panel. 

The  KMR  project  is  supported  by  Award  Number: 
W81XWH-06-2-0074  awarded  and  administered 
through  the  U.S.  Army  Medical  Research 
Acquisition  Activity,  820  Chandler  Street,  Fort 
Detrick  MD  21702-5014.  The  opinions  of  the  authors 
expressed  herein  do  not  necessarily  state  or  reflect 
those  of  the  United  States  Government,  and  shall  not 
be  used  for  advertising  or  product  endorsement 
purposes. 
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Draft  Agreement 

100% 

34  days? 

Thu  5/28/09 

Tue  7/14/09 

Chnsty, Tammy 

37 

✓ 

Draft  reviewed  by  Geneva 

100% 

34  days? 

Wed  5/27/09 

Mon  7/13/09 

Christy 

36 

Draft  reviewed  by  ASU 

100% 

1  day? 

Wed  5/27/09 

Wed  5/27/09 

Tammy 

39 

>/ 

Signed  by  Geneva 

100% 

1  day 

Tue  7/14/09 

Tue  7/14/09  37 

Christy 

40 

v' 

Signed  by  ASU 

100% 

1  day? 

Tue  7/14/09 

Tue  7/14/09  38 

Tammy 

41 

ASU  SOW  and  Budget 

72% 

100  days? 

Mon  6/1/09 

Frl  10/16/09 

Emory, Doug 

42 

Draft  of  ASU  SOW  and  Budget 

100% 

74  days? 

Mon  6/1/09 

Thu  9/10/09 

Emory 

43 

v' 

Review  documents  by  Geneva 

100% 

1  day? 

Thu  9/10/09 

Thu  9/10/09 

Christy 

44 

V 

Agreement  created  by  Geneva  Foundation 

100% 

1  day? 

Fri  9/1 1/09 

Fri  9/1 1/09  43 

Christy 

45 

a 

Agreement  for  Modification  Forwarded  to  ASU  by 

Geneva 

50% 

41  days 

Thu  7/16/09 

Thu  9/10/09 

Christy 

46 

E3 

Agreement  for  Modification  Signed  by  ASU 

0% 

Odays 

Fri  10/16/09 

Fri  10/16/09  43.45 

ASU 

47 

Task  Deliverables 

0% 

230  days? 

Sun  11/15/09 

Thu  9/30/10 

ASU 

48 

a 

Academic  Panel  Discussion  On  CDS  presented  at  AMIA 

0% 

1  day 

Sun  11/15/09 

Sun  11/15/09 

ASU 

49 

Academic  Review  of  CDS  'state  of  the  art1 

0% 

1  day? 

Frl  2/26/10 

Frl  2/26/10 

ASU 

' 

a 

Journal-quality  academic  publication  summarizing 
previous  work 

0% 

0  days 

Fri  2/26/10 

Fri  2/26/10 

ASU 
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ID 

o 

“3i~ 

0 

52 

0 

53~~ 

0 

54 

55  ~ 

0 

56 

0 

_ 57~~ 

0 

58 

0 

59  ' 

60 

0 

61 

0 

62  ' 

~63~ 

0 

*64 

0 

65 

0 

66 

_____ 

0 

68 

0 

69 

70* 

71 

0 

72 

0 

73 

✓ 

74 

>/ 

75 

|Task  Name 


Review  functional  elements  of  a  guideline  and  current 
abstract  models 

Review  languages  for  expressing  guidelines  (current 
syntax  approaches) 

Define  missing  components/  capabilities  and  discuss 
priorities 

Academic  Presentation  &  Demonstration  of  Runtime 
Deliverables 

HIMSS  '10  presentation  of  the  KMR  system  using  a 

demonstration  use  case 

Develop  a  demo  script  and  formal  presentation 

Develop  supplemental  content  /  data  /  metadata  for 
demo  script 

Journal-quality  academic  publication 
Academic  Review  of  completed  KMR  Project 

Formal  presentation  of  KMFt/MS  work  ©AMIA  '10 
Journal-quality  academic  publication  of  work  in  Fall  '10 

Academic  Outcome  &  Usability  Evaluations 

Plan  and  execute  KMR  usability  evaluation  at  Indian 
Medical  Center  Phoenix,  A Z  summer  2010 
Collect  usability  and  outcome  metrics 

Journal-quality  academic  publication 

Document  Metadata,  Terminologies  A  Value  Sets  for 
Runtime  Engine  and  Knowledge  Management 

Document  the  Knowledge  Module  Information  model 
based  on  the  functional  and  semantic  requirements  for 
Identify  standardized  terminologies  for  value  sets  (i.e., 
LOINC,  SNOMED,  etc)  or  create  ■placeholder'  value 
sets  for  concepts  without  exiting  applicable 
Medsphere  Sub-Award 

Admin  Tasks 

Draft  SOW  and  Budget  to  Geneva  for  Review 
Review  of  documents  by  Geneva 
Sole  Source  Justification 

Agreement  for  Modification  Forwarded  to  Medsphere  by 
Geneva 

Agreement  for  Modification  Signed  by  Medsphere 


%  Work 
Comolete 

Duration 

Start 

Finish 

Predecessors 

|Resource  Names 

0% 

1  day? 

Fri  2/26/10 

Fri  2/26/10 

ASU 

0% 

i  day? 

Fri  2/26/10 

Fri  2/26/1 0 

ASU 

0% 

1  day? 

Fri  2/26/10 

Fri  2/26/10 

ASU 

0% 

1  day? 

Mon  3/1/10 

Mon  3/1/10 

ASU 

0% 

1  day? 

Mon  3/1/10 

Mon  3/1/10 

ASU 

0% 

1  day? 

Mon  3/1/10 

Mon  3/1/10 

ASU 

0% 

1  day? 

Mon  3/1/10 

Mon  3/1/10 

ASU 

0% 

0  days 

Mon  3/1/10 

Mon  3/1/10 

ASU 

0% 

1  day? 

Thu  9/30/10 

Thu  9/30/10 

ASU 

0% 

1  day 

Thu  9/30/10 

Thu  9/30/10 

ASU 

0% 

1  day? 

Thu  9/30/10 

Thu  9/30/10 

ASU 

0% 

1  day? 

Thu  9/30/10 

Thu  9/30/10 

ASU 

0% 

1  day? 

Thu  9/30/10 

Thu  9/30/10 

ASU 

0% 

1  day? 

Thu  9/30/10 

Thu  9/30/1 0 

ASU 

0% 

0  days 

Thu  9/30/10 

Thu  9/30/10 

ASU 

0% 

1  day? 

Fri  2/26/10 

Fri  2/26/10 

ASU 

0% 

1  day? 

Fri  2/26/10 

Fri  2/26/10 

ASU 

0% 

I  day? 

Fri  2/26/10 

Fri  2/26/10 

ASU 

1% 

298  days7 

Fri  7/24/09 

Fri  9/10/10 

13% 

86  days? 

Fri  7/24/09 

Wed  11/18/09 

0% 

43  days? 

Fri  7/24/09 

Tue  9/22/09 

Emory 

50% 

1  day? 

Fri  10/9/09 

Fri  10/9/09  71 

Christy 

100% 

5  days? 

Tue  8/25/09 

Mon  8/31/09 

Emory 

100% 

1  day 

Mon  10/12/09 

Mon  10/12/09  72 

Christy 

100% 

0  days 

Wed  11/18/09 

Wed  11/18/09  74 

MEDSPHERE 
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[Task  Name 


78  a 

TsT  3 

eo  "  [3 
81'  a 
82  3 

83~ 

84  3 

"85  [3 

86  '3 
"87  “3 
”88 

89  3 

”90  3 

81  0 
92  3 

"93  "  3 

94 

95  3 

98  3 

"97  3 

"98  ~  3 

99  "3 
‘ioo  "  3 
101I3 


Task  Deliverables 

Establish  SCRUM  based  development  environment 

Host  Medsphere/KMR  planning  and  kick-off  meeting 

Implement  Medsphere  SCRUM  and  Sprint  planning 
process 

Validate  KMR  task  requirements  and  system  design 
within  RPMS  Infrastructure. 

Deliver  Research  Development  Plan 

Obtain  Government  approval  of  Research 
Development  Plan. 

Develop  and  Implement  web  service  data  access  tier  foi 

Create  and  deliver  Requirements  and  Design 
Documents. 

Develop  Web  Services 

Update  existing  API  documentation  as  requirement 
Deliver  Source  Code. 

Incorporate  KMR  GUI  Services  and  CDS  Service  Infrastr 
Create  and  deliver  Requirements  and  Design 
Documents 

Integrate  KMR  Messaging  Infrastructure 

Integrate  MedAJert  screens/functionality  to  interact  with 
surfaced  alerts. 

Update  User  Interlace  Framework  API  documentation 
Deliver  Source  Code 

Optimize  Open  Source  Drools  Infrastructure  for  clinical 
Create  and  deliver  Requirements  and  Design 
Documents. 

Expose  Drools  inference  engine  functioned  capabilities 

as  a  callable  web  service 

Ensure  semantic  constraint  and  terminology 

conformance  during  rule  authoring 

Incorporate  Drools  rules  repository  into  KMR  data 

model 

Develop  infrastructure  framework  for  robust  authoring 
of  rules 

Provide  rule  test  and  evaluation  tools  to  load,  execute 
and  analyze  rule  logic  /  integrity,  and  performance 
Update  Drools  documentation. 

SOADEX  Sub-Award 


%  Work 
ComDlete 

Duration 

Start 

Finish  jPredecessors 

|Resource  Names 

0% 

227  days? 

Mon  11/2/09 

Frl  9/10/10 

0% 

13  days? 

Mon  11/2/09 

Mon  1 1/16/09 

MEDSPHERE 

0% 

1  day? 

Mon  11/2/09 

Mon  11/2/09 

MEDSPHERE 

0% 

1  day? 

Mon  1 1/2/09 

Mon  11/2/09 

MEDSPHERE 

0% 

4  days 

Tue  11/3/09 

Fri  11/6/09 

MEDSPHERE 

0% 

5  days 

Mon  11/9/09 

Fri  11/13/09 

MEDSPHERE 

0% 

1  day? 

Mon  11/16/09 

Mon  11/16/09 

MEDSPHERE 

0% 

75  days? 

Mon  11/16/09 

Frl  2/26/10 

MEDSPHERE 

0% 

1 1  days? 

Mon  11/16/09 

Mon  1 1/30/09 

MEDSPHERE 

0% 

65  days? 

Mon  11/30/09 

Fri  2/26/10 

MEDSPHERE 

0% 

51  days? 

Mon  11/30/09 

Mon  2/8/10 

MEDSPHERE 

0% 

1  day? 

Mon  2/8/10 

Mon  2/8/10 

MEDSPHERE 

0% 

36  days? 

Mon  11/16/09 

Mon  1/4/10 

MEDSPHERE 

0% 

10  days? 

Mon  11/16/09 

Fri  11/27/09 

MEDSPHERE 

0% 

29  days? 

Mon  11/16/09 

Thu  12/24/09 

MEDSPHERE 

0% 

21  days? 

Mon  12/7/09 

Mon  1/4/10 

MEDSPHERE 

0% 

21  days? 

Mon  12/7/09 

Mon  1/4/10 

MEDSPHERE 

0% 

1  day? 

Mon  1/4/10 

Mon  1/4/10 

MEDSPHERE 

0% 

227  days? 

Mon  1 1/2/09 

Frl  9/10/10 

MEDSPHERE 

0% 

215  days'’ 

Mon  11/16/09 

Fri  9/10/10 

MEDSPHERE 

0% 

36  days? 

Mon  11/16/09 

Mon  1/4/10 

MEDSPHERE 

0% 

40  days7 

Mon  1/4/10 

Fri  2/26/10 

MEDSPHERE 

0% 

65  days? 

Mon  3/1/10 

Fri  5/28/10 

MEDSPHERE 

0% 

45  days? 

Mon  5/31/10 

Fri  7/30/10 

MEDSPHERE 

0% 

25  days7 

Mon  8/2/10 

Fri  9/3/10 

MEDSPHERE 

0% 

222  days? 

Mon  11/2/09 

Fri  9/3/10 

MEDSPHERE 

50% 

372  days? 

Frl  VI 109 

Thu  9/30/10 

Page  4 


0317  19  am  10-28-2009 


_  * 

103  / 

104  /' 

_ 1  05  y/' 

106  / 
"T07  ,/ 

~108~  y/ 

_ 109  _  y/ 

'  TlO"  y/ 

"TfT  y/ 

'  112  "  y/ 

113  Ay/' 


Tl5  ‘  y/ 

116  y/ 

Tl7“  y/ 
1  1  Q  y/ 

_ 119  y/ 

120  y/ 

121  y/ 

122  y/ 

_ ISO  y/ 

'124  '  y/ 

*125  1/ 


'Task  Name 


'127  p 


Admin  Tasks 


Draft  SOW  and  Budget  to  Geneva  tor  Review 

Review  of  documents  by  Geneva/SOADEX 

Sole  Source  Justification 

Agreement  created  by  Geneva  Foundation 

Agreement  Forwarded  to  SOADEX  by  Geneva 

Agreement  Signed  by  SOADEX 

Modification  to  Agreement 

Modification  Written  and  Forwarded  to  Geneva 

Agreement  for  Modification  Forwarded  to  SOADEX  by 
Geneva 

Agreement  tor  Modification  Signed  by  SOADEX 

Task  Deliverables 

Phase  1  -  Preliminary  Requirement  and  System  Design 
Review 

Provide  a  Draft  of  Functional  Requirement  Document 
detailing  system  funcationaJ  capabilities 
Preliminary  Project  Plan 

Plan  and  Facilitate  Requirement  Review  Meetings 

Phase  2  -Final  Functional  Requirements,  Use  Case 
Documentation,  UML  Artifacts  and  Meeting 

Subject  Matter  Expert  Requirement  Review 

Final  Functional  Requirements  Document 

Phase  3  -  "Final  system  Design  Documentation,  UML, 
Artifacts,  meeting  facilitation,  and  Engineering  Plan" 

KMR  Schema  and  KMR  Documentation 

Final  Project  Plan  and  Engineering  Plan 

Final  System  Design  Documentation 

Phase  4  -  Final  Quality  Assurance  Plan  and  Testing 
Services 

Final  Quality  Assurance  Plan 


%  Work 
Complete, 
100% 


Page  5 


Duration 


Start 


Finish 


iResource  Names 


iPredecessors 


115  days? 

Frl  5/1/09 

Thu  10/8/09 

57  days? 

Fri  5/1/09 

Mon  7/20/09 

Fateh, Emory 

4  days? 

Tue  7/21/09 

Fri  7/24/09  104 

Christy,  Fateh 

52  days? 

Fri  5/8/09 

Mon  7/20/09 

Emory 

1  day7 

Fri  7/24709 

Sat  7/25/09  106 

Christy 

7  days 

Fri  9/25/09 

Mon  10/5/09 

Christy 

1  day 

Tue  10/6/09 

Tue  10/6/09  105,108 

SOADEX 

63  days? 

Tue  7/14/09 

Thu  10/8/09 

Fateh, Emory 

51  days? 

Tue  7/14/09 

Tue  9/22/09 

Emory 

1  day? 

Thu  10/8/09 

Thu  10/8/09  111 

Christy 

1  day? 

Thu  10/8/09 

Thu  10/8/09 

SOADEX 

354  days? 

Wed  5/27/09 

Thu  9/30/10 

SOADEX 

57  days 

Wed  5/27/09 

Thu  8/13/09 

SOADEX 

26  days 

Wed  5/27/09 

Wed  7/1/09 

SOADEX 

57  days 

Wed  5/27/09 

Thu  8/13/09 

SOADEX 

3  days 

Wed  5/27/09 

Fri  5/29/09 

SOADEX 

4  days? 

Wed  7/1/09 

Mon  7/6/09 

SOADEX 

4  days? 

Wed  7/1/09 

Mon  7/6/09 

SOADEX 

4  days? 

Wed  7/1/09 

Mon  7/6/09 

SOADEX 

26  days 

Frl  7/10/09 

Sat  8/15/09 

SOADEX 

26  days 

Fri  7/10/09 

Sat  8/15/09 

SOADEX 

9  days 

Sat  8/1/09 

Thu  8/13/09 

SOADEX 

25  days 

Mon  7/13/09 

Sat  8/15/09 

SOADEX 

255  days? 

Tue  10/13/09 

Thu  9/30/10 

SOADEX 

11  days  Tue  10/13/09  Tue  10/27/09 


SOADEX 
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10 

o 

[Task  Name 

%  Work 
Comolete 

Duration 

Start 

Finish  [Predecessors 

[Resource  Names 

120 

B 

Quality  Assurance  &  Testing  Services 

0% 

244  days? 

Wed  10/26/09 

Thu  9/30/10 

SOADEX 

'  129 

✓ 

Budget 

100% 

93  days? 

Mon  6/8/09 

Thu  10/15/09 

130 

V 

Admin  Tasks 

100% 

65  days? 

Thu  7/16/09 

Thu  10/1 5/09 

131 

V 

Indirect  Funding  Source  Determined 

100% 

26  days? 

Thu  7/16/09 

Thu  8/20/09 

Emory 

132 

>/ 

Budget  documentation  forwarded  to  Geneva 

100% 

1  day 

Fri  9/25/09 

Fri  9/25/09 

Emory 

133" 

Submit  Budget  lor  Approval 

100% 

1  day 

Fri  10/2/09 

Fri  10/2/09 

Christy 

134 

Budget  Approved 

100% 

0  days 

Thu  10/15/09 

Thu  10/15/09 

Lisa 

"  135 

V 

Travel 

100% 

77  days? 

Mon  6/8/09 

Tue  9/22/09 

136 

Itemize  and  Justify 

100% 

77  days? 

Mon  6/8/09 

Tue  9/22/09 

Emory 

137 

Pricing 

100% 

77  days7 

Mon  6/8/09 

Tue  9/22/09 

Emory 

"138 

✓ 

Supplies 

100% 

77  days? 

Mon  6/8/09 

Tue  9/22/09 

139 

Itemization  Cost 

100% 

77  days? 

Mon  6/8/09 

Tue  9/22/09 

Emory 

~  140 

✓ 

Equipment 

100% 

60  days? 

Mon  6/8/09 

Fri  8/28/09 

141 

Justifications  including  any  "sole  source'  purchases 

100% 

60  days? 

Mon  6/8/09 

Fri  8/28/09 

Emory 

_ 142 

V 

Quotes 

100% 

60  days? 

Mon  6/8/09 

Fri  8/28/09 

Emory 

143“ 

Reporting 

33% 

350  days? 

Tua  6/30/09 

Thu  10/28/10 

144 

Quarterly  Reporting  to  USAMRAA 

43% 

275  days? 

Tue  6/30/09 

Thu  7/15/10 

145 

v' 

Apr  -  Jun  2009  Period 

100% 

12  days? 

Tue  6/30/09 

Wed  7/15/09 

Trish,  Emory 

146 

V 

Jul  -  Sept  2009  Period 

100% 

12  days? 

Wed  9/30/09 

Thu  10/15/09 

Trish.Emory 

147 

B 

Oct  -  Dec  2009  Penod 

0% 

1 3  days? 

Wed  12/30/09 

Fri  1/15/10 

Tnsh.  Emory 

148 

B 

Jan  -  Mar  2010  Period 

0% 

6.5  days? 

Wed  4/7/10 

Thu  4/15/10 

Trish.Emory 

149" 

B 

April  -  June  2010  Period 

0% 

6.5  days? 

Wed  6/30/10 

Thu  7/8/10 

Trish.Emory 

~  150 

jl3 

Jul  -  Sept  2010  Period 

0% 

6  days? 

Thu  7/8/10 

Thu  7/15/10 

Trish.Emory 

'  151 

Yearly  Report  to  USAMRAA 

5% 

273  days? 

Thu  10/15/09 

Thu  10/28/10 

154 

Engineering 

46% 

427  days? 

Mon  2/16/09 

Fri  10/1/10 

Page  6 
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ID 

o 

Task  Name 

%  Work 
Comolete 

Duration 

Stan 

Finish  jPredecessors 

jResource  Names 

155 

Release  #1 

96% 

195  days 

Mon  2/16/09 

Frl  11/13/09 

156 

v' 

Sprint  1  (Set-Up) 

100% 

10  days 

Mon  2/16/09 

Frl  2/27/09 

157 

v' 

Sprint  Planning 

100% 

1  day 

Mon  2/16/09 

Mon  2/16/09 

150 

User  Story  Additions 

100% 

1  day 

Mon  2/16/09 

Mon  2/16/09 

Emory 

"159“] 

✓ 

Backlog  Prioritization 

100% 

1  day 

Mon  2/16/09 

Mon  2/16/09 

KMR  Team 

160 

Documentation  Review 

100% 

1  day 

Mon  2/16/09 

Mon  2/16/09 

KMR  Team 

161 

Deliverables 

100% 

9  days 

Tue  2/17/09 

Frl  2/27/09 

162 

Development  &  QA  Environment  Setup 

100% 

9  days 

Tue  2/17/09 

Fri  2/27/09 

KMR  Team 

“  163 

v' 

Team  Collaboration  Wiki 

100% 

9  days 

Tue  2/17/09 

Fri  2/27/09 

KMR  Team 

164 

✓ 

Source  Code  Repository 

100% 

9  days 

Tue  2/17/09 

Fri  2/27/09 

KMR  Team 

16®“ 

Software  Defect  Tracking  System 

100%. 

9  days 

Tue  2/17/09 

Fri  2/27/09 

KMR  Team 

~  166“ 

v' 

Sprint  2  (DDSS  Install) 

100% 

10  days 

Mon  3/2/09 

Frl  3/13/09  156 

“167“ 

Sprint  Planning 

100%. 

1  day 

Mon  3/2/09 

Mon  3/2/09 

168 

X/ 

User  Story  Additions 

100%. 

1  day 

Mon  3/2/09 

Mon  3/2/09 

Emory 

169 

>/ 

Backlog  Prioritization 

100%. 

1  day 

Mon  3/2/09 

Mon  3/2/09 

KMR  Team 

170 

>/ 

Documentation  Review 

100%. 

1  day 

Mon  3/2/09 

Mon  3/2/09 

KMR  Team 

171 

x/ 

Deliverables 

100% 

9  days 

Tue  3/3/09 

Frl  3/13/09 

172 

✓ 

Install  existing  Fact  Handler 

100%. 

9  days 

Tue  3/3/09 

Fri  3/1 3/09 

KMR  Team 

~  173  " 

✓ 

Install  existing  Task  Manager 

100%. 

9  days 

Tue  3/3/09 

Fri  3/13/09 

KMR  Team 

174 

✓ 

Install  existing  Mirtb  Integration  engine 

100% 

9  days 

Tue  3/3/09 

Fri  3/13/09 

KMR  Team 

“175 

>/ 

Install  existing  Oracle  Jess  Rules  engine 

100%. 

9  days 

Tue  3/3/09 

Fri  3/13/09 

KMR  Team 

“176' 

* 

Sprint  3  (Requirements  *1) 

100%. 

10  days 

Mon  3/16/09 

Frl  3/27/09  166 

177 

v' 

Sprint  Planning 

100% 

1  day 

Mon  3/16/09 

Mon  3/16/09 

178 

K 

User  Story  Additions 

100%. 

1  day 

Mon  3/16/09 

Mon  3/16/09 

Emory 

“179“ 

k 

Backlog  Prioritization 

100%. 

1  day 

Mon  3/16/09 

Mon  3/16/09 

KMR  Team 

Page  7 


•  i 

_  iTask  Name 

o 

%  Work 
Comdete 

Duration 

Start 

Finish 

Predecessors 

Resource  Names 

180 

✓ 

Documentation  Review 

100% 

1  day 

Mon  3/16/09 

Mon  3/1 6/09 

KMR  Team 

181 

v' 

Deliverables 

100% 

9  days 

Tue  3/17/09 

Frl  3/27/09 

ik  J 

✓ 

Review/document  current  middle  tier  functions 

100% 

9  days 

Tue  3/17/09 

Fri  3/27/09 

KMR  Team 

183 

Review/document  functional  scenarios 

100% 

9  days 

Tue  3/17/09 

Fn  3/27/09 

SOADEX 

"184  ' 

Sprint  4  (Requirements  #2) 

100% 

10  days 

Mon  3/30/09 

Frl  4/10/09  176 

185 

Sprint  Planning 

100% 

1  day 

Mon  3/30/09 

Mon  3/30/09 

189 

>/ 

Deliverables 

100% 

9  days 

Tue  3/31/09 

Frl  4/10/09 

190 

V 

Identify  "Milestones  To  Health"  requirements 

100% 

9  days 

Tue  3/31/09 

Fri  4/10/09 

KMR  Team 

191 

>/ 

Identify  Provider  Inbox  requirements 

100% 

9  days 

Tue  3/31/09 

Fri  4/10/09 

KMR  Team 

192 

v' 

Identity  MedAlert  requirements 

100% 

9  days 

Tue  3/31/09 

Fri  4/10/09 

KMR  Team 

193 

Identify  Rule  Workbench's  requirements 

100% 

9  days 

Tue  3/31/09 

Fri  4/10/09 

KMR  Team 

194 

✓ 

Identify  Patient  Medical  Record  requirements 

100% 

9  days 

Tue  3/31/09 

Fri  4/10/09 

KMR  Team 

'195 

v' 

Sprint  5  (Design) 

100% 

10  days 

Mon  4/13/09 

Frl  4/24/09  184 

196 

Sprint  Planning 

100% 

1  day 

Mon  4/13/09 

Mon  4/13/09 

197 

'  198  “ 

✓ 

User  Story  Additions 

100% 

1  day 

Mon  4/13/09 

Mon  4/13/09 

Emory 

✓ 

Backlog  Prioritization 

100% 

1  day 

Mon  4/13/09 

Mon  4/13/09 

KMR  Team 

199 

Documentation  Review 

1 00% 

1  day 

Mon  4/13/09 

Mon  4/13/09 

KMR  Team 

200 

✓ 

Deliverables 

100% 

9  days 

Tue  4/14/09 

Frl  4/24/09 

201 

✓ 

Review/document  Mirth  Channels  Design 

100% 

9  days 

Tue  4/14/09 

Fri  4/24/09 

KMR  Team 

202 

Review/document  Event  Service  Design 

100% 

9  days 

Tue  4/14/09 

Fri  4/24/09 

KMR  Team 

203 

✓ 

Review/document  Data  Transformation  Service  Design 

100% 

9  days 

Tue  4/14/09 

Fri  4/24/09 

KMR  T earn 

"204 

>/ 

Review/document  Clinical  Decision  Support  Service  Design 

100% 

9  days 

Tue  4/14/09 

Fri  4/24/09 

KMR  Team 

205  ' 

Review/document  Knowledge  Management  Service  Design 

100% 

9  days 

Tue  4/14/09 

Fn  4/24/09 

KMR  T earn 

206~ 

✓ 

Review/document  Task  Service  Design 

100% 

9  days 

Tue  4/14/09 

Fri  4/24/09 

KMR  Team 

207 

!✓ 

Review/document  GUI  Service  Design 

100% 

9  days 

Tue  4/14/09 

Fri  4/24/09 

KMR  Team 

Page  8 


03  18  25  am  10-28-2009  10/23 


ID 

0 

Task  Name 

%  Work 
Comolete  | 

Duration 

_ J 

Start 

Finish  Predecessors 

(Resource  Names 

L . 

208 

Review/document  Common  Access  layer  Design 

100% 

9  days 

Tue  4/14/09 

Fri  4/24/09 

KMR  Team 

209 

>/ 

Review/document  Bus  Orchestration  Service  Design 

100% 

9  days 

Tue  4/14/09 

Fri  4/24/09 

KMR  Team 

210 

Sprint  6  (Design) 

100% 

10  days 

Mon  4/27/09 

Frl  5/8/09  195 

211 

V 

Sprint  Planning 

100% 

1  day 

Mon  4/27/09 

Mon  4/27/09 

212 

User  Story  Additions 

100% 

1  day 

Mon  4/27/09 

Mon  4/27/09 

Emory 

.  . 

213 

*/ 

Backlog  Prioritization 

100% 

1  day 

Mon  4/27/09 

Mon  4/27/09 

KMR  Team 

214 

Documentation  Review 

100% 

1  day 

Mon  4/27/09 

Mon  4/27/09 

KMR  Team 

215 

Deliverables 

100% 

9  days 

Tue  4/28/09 

Frl  5/8/09 

216 

Review/documenl  MedAlert  Design 

100% 

9  days 

Tue  4/28/09 

Fri  5/8/09 

KMR  Team 

217 

Review/document  MedAlert  Design 

100% 

9  days 

Tue  4/28/09 

Fri  5/8/09 

KMR  Team 

218 

✓ 

Review/document  MedAlert  Design 

100% 

9  days 

Tue  4/28/09 

Fn  5/8/09 

KMR  Team 

219 

V 

Review/document  MedAlert  Design 

100% 

9  days 

Tue  4/28/09 

Fri  5/8/09 

KMR  Team 

"220 

S 

Review/document  MedAlert  Design 

100% 

9  days 

Tue  4/28/09 

Fri  5/8/09 

KMR  Team 

221 

V' 

Review/document  MedAlert  Design 

100% 

9  days 

Tue  4/28/09 

Fri  5/8/09 

KMR  Team 

222 

s/ 

Sprint  7  (Mirth  Channels) 

100% 

10  days 

Mon  5/11/09 

Frl  5/22/09  210 

'223 

>/ 

Sprint  Planning 

100% 

1  day 

Mon  5/11/09 

Mon  5/11/09 

224 

✓ 

User  Story  Additions 

100% 

1  day 

Mon  5/1 1/09 

Mon  5/11/09 

Emory 

225 

✓ 

Backlog  Prioritization 

100% 

I  day 

Mon  5/11/09 

Mon  5/11/09 

KMR  Team 

226 

Documentation  Review 

100% 

t  day 

Mon  5/1 1/09 

Mon  5/1 1/09 

KMR  Team 

227 

\S 

Deliverables 

100% 

9  days 

Tue  5/12/09 

Frl  5/22/09 

'228 

K' 

Intial  Implementation  of  Mirth  Channels  as  NHIN  Service 

100% 

9  days 

Tue  5/12/09 

Fri  5/22/09 

KMR  Team 

229* 

K 

Sprint  8  (Initial  Documentation) 

100% 

10  days 

Mon  5/25/09 

Frl  6/5/09  222 

230" 

✓ 

Sprint  Planning 

100% 

1  day 

Mon  5/25/09 

Mon  5/25/09 

"231 

v' 

User  Story  Additions 

100% 

1  day 

Mon  5/25/09 

Mon  5/25/09 

Emory 

"232" 

v' 

Backlog  Prioritization 

100% 

1  day 

Mon  5/25/09 

Mon  5/25/09 

KMR  Team 

Page  9 

o 

CD 

< 


ID 

o 

jTask  Name 

233 

✓ 

Documentation  Review 

234  " 

Deliverables 

235 

v' 

Deliver  Initial  Documentation  Set 

236 

v' 

Sprint  9  (Fact  Handler  Component) 

237 

v' 

Sprint  Planning 

238 

User  Story  Additions 

239 

✓ 

Backlog  Prioritization 

240 

✓ 

Documentation  Review 

241 

Deliverables 

242 

✓ 

Intial  Implementation  of  Fact  Handler  as  NHIN  Service 

243 

v" 

Sprint  10  (Event  Service) 

244 

Sprint  Planning 

245 

User  Story  Additions 

246 

✓ 

Backlog  Prioritization 

247 

✓ 

Documentation  Review 

248 

Deliverables 

249 

Intial  Implementation  ol  Event  Service  as  NHIN  Service 

250 

y 

Sprint  11  Clinical  Decision  Support  Serivce 

251 

y 

Sprint  Planning 

252  ~ 

User  Story  Additions 

253 

w 

Backlog  Prioritization 

254 

>/ 

Documentation  Review 

'  255“ 

V 

Deliverables 

“  256“ 

V 

Intial  Implementation  of  Clinical  Decision  Support  Service 
as  NHIN  Service 

257 

V 

Sprint  12  (KMR  Data  Model) 

%  Work  1 
Comolete  1 

Duration  | 

Start 

Finish  (Predecessors 

jResource  Names 

100%” 

1  day 

Mon  5/25/09 

Mon  5/25/09 

KMR  Team 

100% 

9  days 

Tue  5/26/09 

Frl  6/5/09 

100% 

9  days 

Tue  5/26/09 

Fri  6/5/09 

KMR  Team 

100% 

10  days 

Mon  6/8/09 

Frl  6/19/09  229 

100% 

1  day 

Mon  6/8/09 

Mon  6/8/09 

100% 

1  day 

Mon  6/8/09 

Mon  6/8/09 

Emory 

100% 

1  day 

Mon  6/8/09 

Mon  6/8/09 

KMR  Team 

100% 

1  day 

Mon  6/8/09 

Mon  6/8/09 

KMR  Team 

100% 

9  days 

Tuc  6/9/09 

Frl  6/19/09 

100% 

9  days 

Tue  6/9/09 

Fri  6/19/09 

KMR  Team 

100% 

10  days 

Mon  6/22/09 

Frl  7/3/09  236 

100% 

1  day 

Mon  6/22/09 

Mon  6/22/09 

100% 

1  day 

Mon  6/22/09 

Mon  6/22/09 

Emory 

100% 

1  day 

Mon  6/22/09 

Mon  6/22/09 

KMR  Team 

100% 

1  day 

Mon  6/22/09 

Mon  6/22/09 

KMR  Team 

100% 

9  days 

Tue  6/23/09 

Frl  7/3/09 

100% 

9  days 

Tue  6/23/09 

Fri  7/3/09 

KMR  Team 

100% 

10  days 

Mon  7/6/09 

Frl  7/17/09  243 

100% 

1  day 

Mon  7/6/09 

Mon  7/6/09 

100% 

1  day 

Mon  7/6/09 

Mon  7/6/09 

Emory 

100% 

1  day 

Mon  7/6/09 

Mon  7/6/09 

KMR  Team 

100% 

1  day 

Mon  7/6/09 

Mon  7/6/09 

KMR  Team 

100% 

9  days 

Tue  7/7/09 

Frl  7/17/09 

100% 

9  days 

Tue  7/7/09 

Fri  7/17/09 

KMR  Team 

100% 

10  days 

Mon  7/20/09 

Frl  7/31/09  250 

Page  10 
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Duration 

Start 

Finish  jPredecessors 

jResource  Names 

1  day 

Mon  7/20/09 

Mon  7/20/09 

1  day 

Mon  7/20/09 

Mon  7/20/09 

Emory 

1  day 

Mon  7/20/09 

Mon  7/20/09 

KMR  Team 

1  day 

Mon  7/20/09 

Mon  7/20/09 

KMR  Team 

9  days 

Tue  7/21/09 

Frl  7/31/09 

9  days 

Tue  7/21/09 

Fri  7/31/09 

KMR  Team 

10  days 

Mon  8/3/09 

Frl  8/14/09  257 

1  day 

Mon  8/3/09 

Mon  8/3/09 

1  day 

Mon  8/3/09 

Mon  8/3/09 

Emory 

1  day 

Mon  8/3/09 

Mon  8/3/09 

KMR  Team 

1  day 

Mon  8/3/09 

Mon  8/3/09 

KMR  Team 

9  day3 

Tue  8/4/09 

Frl  8/14/09 

9  days 

Tue  8/4/09 

Fri  8/14/09 

KMR  Team 

10  days 

Mon  8/17/09 

Frl  8/28/09  264 

1  day 

Mon  8/17/09 

Mon  8/17/09 

1  day 

Mon  8/17/09 

Mon  8/17/09 

Emory 

1  day 

Mon  8/17/09 

Mona/17/09 

KMR  Team 

1  day 

Mon  8/17/09 

Mon  8/17/09 

KMR  Team 

9  days 

Tue  8/18/09 

Frl  8/28/09 

9  days 

Tue  8/18/09 

Fri  8/28/09 

KMR  Team 

10  days 

Mon  8/31/09 

Frl  9/11/09  271 

1  day 

Mon  8/31/09 

Mon  8/31/09 

1  day 

Mon  8/31/09 

Mon  8/31/09 

Emory 

1  day 

Mon  8/31/09 

Mon  8/31/09 

KMR  Team 

1  day  Mon  8/3 1/09  Mon  8/31/09 


KMR  Team 


031912am  10-28-2009  13/23 


ID 

O 

283 

x/ 

‘284  - 

285" 

</ 

"286  " 

✓ 

287 

V 

‘288 

*/ 

"289  ' 

•s 

290 

✓ 

291 

292  " 

V 

293 

V 

294 

V 

295" 

~296 

~3b6  ~ 

55T 

a 

"  302_ 

303 

—364— 

S3 

— 305  — 

3 

"306 

0 

"307 

"308" 

0 

309 

"310  _ 

T ask  Name 

Deliverables 

Intial  Implementation  of  Provider  Inbox  as  NHIN  Service 
Sprint  16  (Data  Transformation  Service) 

Sprint  Planning 

User  Story  Additions 
Backlog  Prioritization 
Documentation  Review 
Deliverables 

Intial  Implementation  of  Data  Transformation  Service  as 
NHIN  Service 

Administrative  Break 

New  Engineering  Lead  and  Development  Process 
Use  Cases  Define  for  Demonstration 
Sprint  17  (GUI  Service) 

Sprint  Planning 
Deliverables 

Intial  Implementation  of  GUI  Service  as  NHIN  Service 
Sprint  18  (MedAlert  Release  #1) 

Sprint  Planning 

User  Story  Additions 
Backlog  Prioritization 
Documentation  Review 
Deliverables 

Intial  Implementation  of  MedAlert  as  NHIN  Client 
Sprint  19  (Integration  Testing) 

Sprint  Planning 


%  Work 
Comolete 

Duration 

Start 

Finish  |Predecessors 

100% 

9  days 

Tue  9/1/09 

Frl  9/1 1/09 

100% 

9  days 

Tue  9/1/09 

Fri  9/1 1/09 

100% 

10  days 

Mon  9/14/09 

Frl  9/25/09  278 

100% 

1  day 

Mon  9/14/09 

Mon  9/14/09 

100% 

1  day 

Mon  9/14/09 

Mon  9/14/09 

100% 

1  day 

Mon  9/14/09 

Mon  9/14/09 

100% 

1  day 

Mon  9/14/09 

Mon  9/14/09 

100% 

9  days 

Tue  9/15/09 

Frl  9/25/09 

100% 

9  days 

Tue  9/15/09 

Fri  9/25/09 

100% 

10  days 

Mon  9/28/09 

Frl  10/9/09  285 

100% 

10  days 

Mon  9/28/09 

Fri  10/9/09 

100% 

10  days 

Mon  9/28/09 

Fri  10/9/09 

0% 

10  days 

Mon  10/12/09 

Frl  10/23/09  292 

0% 

1  day 

Mon  10/12/09 

Mon  10/12/09 

0% 

9  days 

Tue  10/13/09 

Frl  10/23/09 

0% 

5  days 

Tue  10/13/09 

Fri  10/23/09 

0% 

10  days 

Mon  10/26/09 

Frl  11/6/09  295 

0% 

1  day 

Mon  10/26/09 

Mon  10/26/09 

0% 

1  day 

Mon  10/26/09 

Mon  10/26/09 

0% 

1  day 

Mon  10/26/09 

Mon  10/26/09 

0% 

1  day 

Mon  10/26/09 

Mon  10/26/09 

0% 

9  days 

Tue  10/27/09 

Frl  11/6/09 

0% 

Odays 

Tue  10/27/09 

Fri  11/6/09 

0% 

5  days 

Mon  11/9/09 

Frl  11/13/09  302 

0% 

1  day 

Mon  11/9/09 

Mon  11/9/09 

jResource  Names 
KMR  Team 

Emory 
KMR  Team 
KMR  Team 

KMR  Team 

KMR  Team 
KMR  Team 


KMR  Team 

Emory 
KMR  Team 
KMR  Team 

KMR  Team 
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03  1928am  10-28-2009  14/23 


ID 

o 

|Task  Name 

311 

a 

User  Story  Additions 

312 

o 

Backlog  Prioritization 

'  313' " 

s 

Documentation  Review 

"314“ 

Deliverables 

a 

Integration  Testing 

“316 

a 

Demonstration  at  AMIA  Meeting 

"317 

Release  #2 

318 

Sprint  20  (Documentation) 

“319 

Sprint  Planning 

320 

a 

User  Story  Additions 

321 

a 

Backlog  Prioritization 

“322 

a 

Documentation  Review 

323 

Deliverables 

324 

a 

Version  2  Of  KMR  Documentation 

“32r~ 

Sprint  21  (Workbench  Release  #1) 

"326“ 

Sprint  Planning 

327 

a 

User  Story  Additions 

328 

a 

Backlog  Pnoritization 

329" 

a 

Documentation  Review 

"330 

Deliverables 

331 

a 

Initial  Implementation  of  Workbench  as  NHIN  Client 

“332 

Sprint  22  (Admin  and  Performance  Monitoring  Tool) 

333 

Sprint  Planning 

334 

a 

User  Story  Additions 

"335 

a 

_  . 

Backlog  Prioritization 

%  Work 
Comolete  I 

Duration 

Start 

Finish  jPredecessors 

jResource  Names 

0% 

1  day 

Mon  11/9/09 

Mon  1 1/9/09 

Emory 

0% 

1  day 

Mon  11/9/09 

Mon  11/9/09 

KMR  Team 

0% 

1  day 

Mon  1 1/9/09 

Mon  11/9/09 

KMR  Team 

0% 

4  days 

Tue  11/10/09 

Frl  11/13/09 

0% 

4  days 

Tue  11/10/09 

Fri  11/13/09 

0% 

1  day 

Sat  11/14/09 

Sat  11/14/09  309 

Emory 

0% 

75  days? 

Mon  11/16/09 

Frl  2/26/10 

0% 

8  days? 

Mon  11/16/09 

Wed  11/25/09 

0% 

1  day? 

Mon  11/16/09 

Mon  11/16/09 

0% 

1  day? 

Mon  11/16/09 

Mon  11/16/09 

0% 

1  day? 

Mon  11/16/09 

Mon  11/16/09 

0% 

1  day7 

Mon  11/16/09 

Mon  11/16/09 

0% 

7  days? 

Tue  11/17/09 

Wed  11/25/09 

0% 

7  days? 

Tue  11/17/09 

Wed  11/25/09 

KMR  Team, Fateh 

0% 

10  days? 

Mon  11/30/09 

Frl  12/11/09 

0% 

1  day? 

Mon  1 1/30/09 

Mon  11/30/09 

0% 

1  day? 

Mon  11/30/09 

Mon  11/30/09 

0% 

1  day? 

Mon  11/30/09 

Mon  11/30/09 

0% 

1  day’’ 

Mon  11/30/09 

Mon  1 1/30/09 

0% 

9  days? 

Tue  12/1/09 

Frl  12/11/09 

0% 

9  days? 

Tue  12/1/09 

Fri  12/1 1/09 

KMR  Team, Fateh 

0% 

9  days? 

Mon  12/1 4/09 

Thu  12/24/09 

0% 

1  day? 

Mon  12/14/09 

Mon  12/14/09 

0% 

1  day? 

Mon  12/14/09 

Mon  12/14/09 

0% 

1  day? 

Mon  12/14/09 

Mon  12/14/09 

Page  13 


Sprint  Planning  0% 

User  Story  Additions  0% 

Backlog  Pnoritization  0% 

Documentation  Review  0% 

Deliverables  0% 

Release  #2  of  the  Workbench  0% 

Sprint  26  (MedAlert  Release  *2  and  KMR)  0% 
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Frl  2/12/10 


03  1958am  10-28-2009 


ID 

o 

jTask  Name 

361  f 

Sprint  Planning 

362“ 

s 

User  Story  Additions 

_ 363 

Backlog  Prioritization 

364 

a 

Documentation  Review 

365 

Deliverables 

“'366 

a 

Release  #2  ol  MedAlert  and  KMR  as  NHIN  Client 

367 

Sprint  27  (Integration  Testing) 

368 

Sprint  Planning 

~369_ 

a 

User  Story  Additions 

'  370  “ 

a 

Backlog  Prioritization 

'  371  “1 

u.  ...j 

a 

Documentation  Review 

372  i 

Deliverables 

373  | 

a 

Integration  Testing 

374"' 

a 

Demonstration  at  HIMSS  Meeting 

375 

Release  *3 

376 

Sprint  28  (Milestone  Editor  Release  #1) 

~yh~ 

Sprint  Planning 

378 

a 

User  Story  Additions 

379 

a 

Backlog  Prioritization 

380 

pa 

Documentation  Review 

381 

Deliverables 

382 

a 

Release  #1  tor  Milestone  Editor  as  NHIN  Client 

383“  ~ 

Sprint  29  (Patient  Portal  Release  Ml) 

CD 

< 

384 

Sprint  Planning 

”385“ 

la 

User  Story  Additions 

%  Work 
Omolete 

Duration  | 

Start 

Finish  jPredecessors 

(Resource  Names 

0% 

1  day? 

Mo“n  2/1/10 

Mon  2/l7io 

0% 

1  day? 

Mon  2/1/10 

Mon  2/1/10 

0% 

1  day’ 

Mon  2/1/10 

Mon  2/1/10 

0% 

1  day7 

Mon  2/1/10 

Mon  2/1/10 

07. 

9  days? 

Tue  2/2/10 

Frl  2/12/10 

0 % 

9  days? 

Tue  2/2/10 

Fri  2/12/10 

KMR  Team. Fateh 

0% 

10  days? 

Mon  2/15/10 

Frl  2/26/10 

0% 

1  day? 

Mon  2/15/10 

Mon  2/15/10 

07. 

1  day? 

Mon  2/15/10 

Mon  2/15/10 

07. 

1  day? 

Mon  2/15/10 

Mon  2/15/10 

0% 

1  day? 

Mon  2/15/10 

Mon  2/15/10 

0% 

9  days? 

Tue  2/16/10 

Frl  2/26/10 

07. 

9  days? 

Tue  2/16/10 

Fri  2/26/10 

KMR  Team, Fateh 

07. 

3  days 

Mon  3/1/10 

Wed  3/3/10 

0% 

70  days? 

Mon  3/8/10 

Frl  6/11/10 

0% 

10  days? 

Mon  3/8/10 

Frl  3/19/10 

0% 

1  day? 

Mon  3/8/10 

Mon  3/8/10 

07. 

t  day? 

Mon  3/8/10 

Mon  3/8/10 

07. 

1  day? 

Mon  3/8/10 

Mon  3/8/10 

07. 

1  day? 

Mon  3/8/10 

Mon  3/8/10 

0% 

9  days? 

Tua  3/9/10 

Frl  3/19/10 

07. 

9  days? 

Tue  3/9/10 

Fri  3/19/10 

KMR  Team, Fateh 

07. 

10  days? 

Mon  3/22/10 

Frl  4/2/10 

0% 

1  day? 

Mon  3/22/10 

Mon  3/22/10 

07. 

1  day? 

Mon  3/22/10 

Mon  3/22/10 

Page  15 


ID 

o 

(Task  Name 

%  Work 
Comolete 

386 

a 

Backlog  Prioritization 

0% 

387 

a 

Documentation  Review 

0% 

388 

Deliverables 

0% 

389 

a 

Release  #1  lor  Patient  Portal  as  NHIN  Client 

0% 

390 

Sprint  30  (Mobile  Tools  Release  *1) 

0% 

391 

Sprint  Planning 

0% 

392 

a 

User  Story  Additions 

0% 

393 

a 

Backlog  Prioritization 

0% 

394 

a 

Documentation  Review 

0% 

395 

Deliverables 

0% 

“  396  ~ 

a 

Release  #1  tor  Mobile  Tools  as  NHIN  Client 

0% 

397 

Sprint  31  (MedAlert  Release  #2) 

0% 

398 

Sprint  Planning 

0% 

399 

a 

User  Story  Additions 

0% 

400"  ' 

a 

Backlog  Prioritization 

0% 

~40t 

a 

Documentation  Review 

0% 

402 

Deliverables 

0% 

403 

a 

Release  42  MedAlert  as  NHIN  Client 

0% 

404 

Sprint  32  (Drools  Optimizations  Release  «  1) 

0% 

405 

Sprint  Planning 

0% 

406" 

a 

User  Story  Additions 

0% 

407 

a 

Backlog  Pnoritization 

0% 

‘  408 

a 

Documentation  Review 

0% 

409 

Deliverables 

0% 

'  410 

a 

Release  41  Drools  Optimizations 

0% 
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Duration  | 
1  day? 
i  day? 

9  days? 
9  days? 

10  days? 
1  day? 

1  day7 
1  day? 
1  day? 
9  days? 
9  days? 

10  days? 
1  day? 
1  day7 
1  day? 
1  day? 

9  days? 
9  days? 

11  days? 
1  day? 
1  day7 
1  day? 
1  day? 

9  days? 


Start 

Finish  'Predecessors 

Mon  3/22/10 

Mon  3/22/10 

Mon  3/22/10 

Mon  3/22/10 

Tue  3/23/10 

Frl  4/2/10 

Tue  3/23/10 

Fri  4/2/10 

Mon  4/5/10 

Frl  4/16/10 

Mon  4/5/10 

Mon  4/5/10 

Mon  4/5/10 

Mon  4/5/10 

Mon  4/5/10 

Mon  4/5/1 0 

Mon  4/5/10 

Mon  4/5/10 

Tue  4/6/10 

Frl  4/16/10 

Tue  4/6/10 

Fri  4/16/10 

Mon  4/19/10 

Frl  4/30/10 

Mon  4/19/10 

Mon  4/19/10 

Mon  4/19/10 

Mon  4/19/10 

Mon  4/19/10 

Mon  4/19/10 

Mon  4/19/10 

Mon  4/19/10 

Tuo  4/20/10 

Frl  4/30/10 

Tue  4/20/10 

Fri  4/30/10 

Mon  5/3/10 

Mon  S/17/10 

Mon  5/3/10 

Mon  5/3/10 

Mon  5/3/10 

Mon  5/3/10 

Mon  5/3/10 

Mon  5/3/10 

Mon  5/3/10 

Mon  5/3/10 

Wed  5/5/10 

Mon  5/17/10 

'Resource  Names 


KMR  Team, Fateh 


KMR  Team, Fateh 


KMR  Team, Fateh 


9  days?  Wed  5/5/10  Mon  5/1 7/1 0 


KMR  Team, Fateh 


03  20  28  am  10-28-2009 


ID 

o 

jTask  Name 

_  _L 

411 

Sprint  33  (Community  Portal  Release  *  1) 

412 

Sprint  Planning 

413 

0 

User  Story  Additions 

414'  ‘ 

0 

Backlog  Pnoritization 

415 

0 

Documentation  Review 

416 

Oellverables 

417 

0 

Release  #1  Community  Portal  as  NHIN  Client 

"418 

Sprint  34  (Integration  Testing) 

419 

Sprint  Planning 

'  420 

a 

User  Story  Additions 

421 

0 

Backlog  Prionbzation 

"422 

0 

Documentation  Review 

423' 

Deliverables 

424 

0 

Integration  Testing 

"425 

Release  *4 

426 

Sprint  35  (Patient  Portal  Release  #2) 

427 

Sprint  Planning 

"  428 

0 

User  Story  Additions 

429" 

0 

Backlog  Prioritization 

430"’ 

0 

Documentation  Review 

431 

Deliverables 

432 

0 

Release  #2  Patient  Portal  as  NHIN  Client 

433 

Sprint  36  (Community  Portal  Release  #  2) 

434 

Sprint  Planning 

~  435 

0 

User  Story  Additions 

CO 


7.  Work 

Duration 

Start 

Finish 

Predecessors  Resource  Names 

Comolete 

0% 

10  days? 

Mon  5/17/10 

Frl  5/28/10 

0% 

1  day? 

Mon  S/17/10 

Mon  5/17/10 

0% 

1  day? 

Mon  5/17/10 

Mon  5/17/10 

07. 

1  day? 

Mon  5/17/10 

Mon  5/17/10 

07. 

1  day? 

Mon  5/17/10 

Mon  5/17/10 

0% 

9  days? 

Tue  5/18/10 

Frl  5/28/10 

07. 

9  days? 

Tue  5/1 8/10 

Fri  5/28/10 

KMR  Team, Fateh 

0% 

9  days? 

Tue  6/1/10 

Frl  6/11/10 

0 % 

1  day? 

Tue  6/1/10 

Tue  6/1/10 

0% 

1  day? 

Tue  6/1/10 

Tue  6/1/10 

07. 

1  day? 

Tue  6/1/10 

Tue  6/1/10 

0% 

1  day? 

Tue  6/1/10 

Tue  6/1/10 

0% 

8  days? 

Wed  6/2/10 

Frl  6/11/10 

07. 

8  days? 

Wed  6/2/10 

Fri  6/11/10 

KMR  Team, Fateh 

0% 

80  days? 

Mon  6/14/10 

Frl  10/1/10 

0% 

10  days? 

Mon  6/14/10 

Frl  6/25/10 

0% 

1  day? 

Mon  6/14/10 

Mon  6/14/10 

07. 

1  day? 

Mon  6/14/10 

Mon  6/14/10 

07. 

1  day? 

Mon  6/14/10 

Mon  6/14/10 

07. 

1  day? 

Mon  6/14/10 

Mon  6/14/10 

0% 

9  days? 

Tue  6/15/10 

Frl  6/25/10 

07. 

9  days? 

Tue  6/15/10 

Fri  6/25/10 

KMR  Team, Fateh 

0% 

10  days? 

Mon  6/28/10 

Frl  7/W10 

0% 

1  day? 

Mon  6/28/10 

Mon  6/28/10 

07. 

1  day? 

Mon  6/28/10 

Mon  6/28/10 
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03  20  43  a  m  10-28-2009 


ID  !- 

© 

|Task  Name 

436 

Backlog  Pnoritization 

437  ] 

E3 

Documentation  Review 

430 

Deliverables 

439 

s 

Release  H2  Community  Portai  Release  as  NHIN  Client 

440 

Sprint  37  (Drools  Optimizations  Release  #  2) 

"441 

Sprint  Planning 

442 

a 

User  Story  Additions 

443 

a 

Backlog  Prioritization 

”444" 

a 

Documentation  Review 

445 

Deliverables 

446 

a 

Release  #2  Drools  Optimizations 

447 

Sprint  38  (Milestone  Editor  Release  #2) 

448 

Sprint  Planning 

"449 

a 

User  Story  Additions 

'450 

a 

Backlog  Pnoritization 

45 1_ 

a 

Documentation  Review 

"  452 

Deliverables 

■453" 

a 

Release  #2  Milestone  Editor  as  NHIN  Client 

454 

Sprint  39  (Mobile  Tools  Release  Release  *2) 

455 

Sprint  Planning 

"456 

a 

Backlog  Prioritization 

457 

a 

Documentation  Review 

458 

Deliverables 

459 

a 

Release  #2  Mobile  Tools 

460 

Sprint  40  (Final  Integration  Testing) 

%  Work 
Comolete 

Duration 

1  1 

Start 

Finish  Predecessors 

j  Resource  Names 

0% 

1  day? 

Mon  6/28/10 

Mon  6/28/10 

0% 

1  day? 

Mon  6/28/10 

Mon  6/28/10 

0% 

9  days? 

Tue  6/29/10 

Frl  7/9/10 

0% 

9  days? 

Tue  6/29/10 

Fri  7/9/10 

KMR  Team, Fateh 

0% 

10  days? 

Mon  7/12/10 

Frl  7/23/10 

0% 

1  day? 

Mon  7/12/10 

Mon  7/12/10 

0% 

1  day? 

Mon  7/12/10 

Mon  7/12/10 

0% 

1  day? 

Mon  7/12/10 

Mon  7/12/10 

0% 

1  day? 

Mon  7/12/10 

Mon  7/12/10 

0% 

9  days? 

Tue  7/13/10 

Frl  7/23/10 

0% 

9  days? 

Tue  7/13/10 

Fn  7/23/10 

KMR  Team, Fateh 

0% 

10  days? 

Mon  8/9/10 

Frl  8/20/10 

0% 

1  day? 

Mon  8/9/10 

Mon  8/9/10 

0% 

1  day? 

Mon  8/9/10 

Mon  8/9/10 

0% 

1  day? 

Mon  8/9/10 

Mon  8/9/10 

0% 

1  day? 

Mon  8/9/10 

Mon  8/9/10 

0% 

9  days? 

Tue  8/10/10 

Frl  8/20/10 

0% 

9  days? 

Tue  8/10/10 

Fri  8/20/10 

KMR  Team,  Fateh 

0% 

10  days? 

Mon  8/23/10 

Frl  9/3/10 

0% 

1  day? 

Mon  8/23/10 

Mon  8/23/10 

0% 

1  day? 

Mon  8/23/10 

Mon  8/23/10 

0% 

1  day? 

Mon  8/23/10 

Mon  8/23/10 

0% 

9  days? 

Tue  8/24/10 

Frl  9/3/10 

0% 

9  days? 

Tue  8/24/10 

Fri  9/3/10 

KMR  Team, Fateh 

0% 

9  days? 

Tue  9/7/10 

Frl  9/17/10 
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03  20  58  a  m  10-28-2009  20  /23 


ID 

O 

jTask  Name 

%  Work 
ComDlete 

461 

Sprint  Planning 

0% 

462 

User  Story  Additions 

0% 

“463 

0 

Backlog  Prioritization 

0% 

“464 

0 

Documentation  Review 

0% 

465 

Deliverables 

0% 

466'  1 

0 

Final  Integration  Testing 

0% 

467 

Sprint  41  (Final  Demonstration) 

0% 

468 

Sprint  Planning 

0% 

469 

0 

User  Story  Additions 

0% 

470 

0 

Backlog  Prioritization 

0% 

471 

0 

Documentation  Review 

0% 

472“ 

Deliverables 

0% 

“473“ 

0 

Final  Demonstration 

0% 

474“ 

Pilot  Demonstration 

7% 

475 

Pilot  Initiation 

15% 

“476 

v" 

Pilot  Concept  Proposal 

100% 

477 

0 

Dratt  Pilot  Project  Plan 

15% 

478  “ 

0 

Final  Pilot  Project  Plan 

0% 

“479“ 

Phoenix  Indian  Medical  Center  Pilot 

0% 

480 

Community  Outreach 

0% 

481 

Phase  1:  Plan  Community  Involvement 

0% 

482“ 

0 

Identify  Stakeholders 

0% 

“483 

0 

Community  Outreach  Concept  Paper 

0% 

"“484 

0 

First  Executive  Community  Steering  Group  Meeting 

0% 

'“485 

Phase  2:  Execute  Community  Outreach 

0% 
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Duration  1 

Start 

1 

Finish  |  Predecessors 

|Resource  Names 

9  days? 

Tue  9/7/10 

Fri  9/17/10 

1  day? 

Tue  9/7/10 

Tue  9/7/10 

1  day7 

Tue  9/7/10 

Tue  9/7/10 

1  day? 

Tue  9/7/10 

Tue  9/7/10 

8  days 

Wed  9/8/10 

Fri  9/17/10 

8  days 

Wed  9/8/10 

Fri  9/17/10 

KMR  Team, Fateh 

10  days? 

Mon  9/20/10 

Fri  10/1/10 

1  day? 

Mon  9/20/10 

Mon  9/20/10 

1  day? 

Mon  9/20/10 

Mon  9/20/10 

1  day? 

Mon  9/20/10 

Mon  9/20/10 

1  day? 

Mon  9/20/10 

Mon  9/20/10 

9  days? 

Tue  9/21/10 

Fri  10/1/10 

9  days? 

Tue  9/21/10 

Fri  10/1/10 

KMR  Team, Fateh 

267  days? 

Mon  8/31/09 

Fri  9/3/10 

85  days? 

Mon  8/31/09 

Wed  12/23/09 

1  day 

Mon  8/31/09 

Mon  8/31/09 

ASU 

52  days? 

Mon  10/5/09 

Fri  12/11/09 

ASU.Terry, Nan, Howard, Trist 

8  days? 

Mon  12/14/09 

Wed  12/23/09 

234  days? 

Thu  10/15/09 

Fri  9/3/10 

Doug  and  Connie 

99  days? 

Thu  10/15/09 

Fri  2/26/10 

34  days? 

Thu  10/15/09 

Fri  11/27/09 

1  day? 

Thu  10/15/09 

Thu  10/15/09 

1  day? 

Fri  10/16/09 

Fri  10/16/09 

1  day? 

Fri  1 1/27/09 

Fri  11/27/09 

Nan 

14  days? 

Mon  1/11/10 

Thu  1/28/10 

Nan 


03  21  13  am  10-28-2009  21  /23 


10 

O 

|Task  Name 

%  Work 
Comolete 

486 

Community  Advisory  Board 

0% 

487  "  | 

E3 

Community  Advisory  Board  #1 

0% 

488 

Town  hall  Meetings 

0% 

489 

a 

Town  hall  Meeting  #1 

0% 

490 

Community  Focus  Groups 

0% 

491  ' 

a 

Community  Focus  Group  Meeting  #1 

0% 

492  j 

Provider  Focus  Groups 

0% 

493  1 

a 

Provider  Focus  Group  Meeting  #1 

0% 

494 

Medical  Center  Briefings 

0% 

495 

a 

IT  Staff  Briefing  41 

0% 

496 

Phase  3:  Community  Needs  Assessment 

0% 

■497- 

a 

Identify  test  group 

0% 

498 

Pilot  Preparation 

0% 

“499  ~ 

Clinical  Decision  Support 

0% 

500“ 

a 

CDS  Protocol  Identification 

0% 

501 

a 

CDS  Content 

0% 

502” 

Deployment  Plan 

0% 

503 

a 

Establish  Production  Architecture 

0% 

504  “ 

a 

Production  Hardware  Requirements 

0% 

505 

Training  Plan 

0% 

506 

ja 

Training  Objectives 

0% 

507 

a 

Training  Resources 

0% 

508~ 

a 

Training  Strategy 

0% 

509 

a 

Training  Content 

0% 

510 

Communication  Plan 

0% 
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ID 

e 

jTask  Name 

%  Work 
Complete 

511 

a 

Draft  Communication  Management  Plan 

0% 

512 

a 

Review  and  Revise 

0% 

"513“ 

a 

Communication  Plan  Approved 

0% 

514 

a 

Implement  Communication  Management  Process 

0% 

515 

Evaluation  Plan 

0% 

516 

a 

System  Metrics 

0% 

517 

a 

Patient  feedback 

0% 

513 

a 

Community  feedback 

0% 

"519 

a 

Provider  feedback 

0% 

“  520 

HIS  Certification  &  Authorization 

<rv. 

521" 

a 

Costing  Plan 

0% 

“522  ~ 

a 

Secure  deployment  resources 

0% 

523 

a 

Deployment  Architecture 

0% 

524 

Pilot  Deployment 

0% 

”525“ 

a 

Identify  each  component 

0% 

526“ 

a 

Costing 

0% 

“527“ 

a 

Secure  deployment  resources 

0% 

528“ 

a 

Establish  Help  Desk 

0% 

529 

a 

Deploy  software 

0% 

“530 “ 

a 

Deployment  complete 

0% 

531 

Pilot  Evaluation 

0% 

“532“ 

a 

Data  Collection 

0% 

533 

a 

System  Metrics 

0% 

534 

a 

Patient  feedback 

0% 

“535“ 

a 

Provider  feedback 

0% 

“536" 

a 

Community  feedback 

0% 
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Duration  Start  j  Finish  [Predecessors  JResource  Names 

20 days?  MorT37l/10  Fri  3/26/10 

20  days?  Mon  3/1/10  Fri  3/26/1 0 

20  days9  Mon  3/1/10  Fri  3/26/10 

20  days?  Mon  3/1/10  Fri  3/26/10 

20  days?  Mon  3/1/10  Fri  3/26/10 

20  days’  Mon  3/1/10  Fri  3/26/10 

20  days  Mon  3/1/10  Fri  3/26/10 

20  days  Mon  3/1/10  Fri  3/26/10 

20  days  Mon  3/1/1 0  Fri  3/26/1 0 

70  days?  Mon  3/29/10  Fri  7/2/10 

70  days?  Mon  3/29/10  Fri  7/2/10 

70  days?  Mon  3/29/10  Fri  7/2/10 

70  days?  Mon  3/29/10  Fri  7/2/1 0 

67  days?  Thu  4/1/10  Fri  7/2/10 

67  days?  Thu  4/1/10  Fri  7/2/10 

67  days?  Thu  4/1  /1 0  Fri  7/2/1 0 

67  days?  Thu  4/1/10  Fri  7/2/10 

67  days?  Thu  4/1/10  Fri  7/2/10 

67  days?  Thu  4/1  /1 0  Fri  7/2/1 0 

67  days?  Thu  4/1/10  Fri  7/2/10 

45  days?  Mon  7/5/10  Fri  9/3/10 

45  days?  Mon  7/5/10  Fri  9/3/10 

45  days?  Mon  7/5/10  Fri  9/3/10 

45  days?  Mon  7/5/10  Fri  9/3/10 

45  days?  Mon  7/5/10  Fri  9/3/10  ASU 

45  days  Mon  7/5/10 


Fri  9/3/10 


ID 

O 

|Task  Name 

%  Work  ) 
Complete 

536 

0 

Community  feedback 

0% 

537 

Pro|ec1  W  trap-Up 

0% 

538 

Protect  Documentation 

0% 

■539 

0 

Functional  Requirements,  Use  Cases,  and  Academic  Review 
(Deliverable  #2) 

0% 

540 

a 

System  Design  Specification  and  Academic  Review  (Deliverable  #3) 

0% 

541 

0 

User  Documentation  (Deliverable  #4) 

0% 

542" 

0 

Metadata  (Deliverable  #6) 

0% 

543  ~ 

0 

Final  Report 

0% 

544 

KMR  Deliverables 

0% 

545 

Metadata  (Deliverable  #6) 

0% 

"~546~ 

0 

Develop  information  model  based  on  functional  and  semantic 
requirements  of  use  cases 

0% 

547 

0 

Identify  standardized  terminologies  for  value  sets  or  crate 
•placeholder"  value  sets  for  concepts 

0% 

548 

Code  Delivery 

0% 

549 

0 

KMR  Repository  and  Guideline  Content  Mgt  System  Delivered 
(Deliverable  #7) 

0% 

550 

0 

Rule  and  Guideline  Runtime  Engine  Delivered  (Deliverable  46) 

0% 

551 

0 

Sys  Adm  Portal  and  Performance  Monitoring  Tool  Delivered 
(Deliverable  #9) 

0% 

552 

0 

Point  of  Care  CDS  Tools  for  AHLTA  Delivered  (Deliverable  #10) 

0% 

“553 

0 

Guideline/Rules  Workbench  and  Authoring  Tools  Delivered 

0% 

— 

(Deliverable  #11) 

— 

o 
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Duration 


Start 


Finish 


[Resource  Names 


45  days 

Mon  7/5/10 

19  days 

Mon  9/6/10 

19  days 

Mon  9/6/10 

19  days 

Mon  9/6/10 

1 9  days 

Mon  9/6/10 

19  days 

Mon  9/6/10 

19  days 

Mon  9/6/10 

19  days 

Mon  9/6/10 

19  days 

Mon  9/6/10 

19  days 

Mon  9/6/10 

19  days 

Mon  9/6/10 

1 9  days 

Mon  9/6/10 

19  days 

Mon  9/6/10 

1 9  days 

Mon  9/6/10 

19  days 

Mon  9/6/10 

19  days 

Mon  9/6/10 

19  days 

Mon  9/6/10 

19  days 

Mon  9/6/10 

Predecessors 
Fri  9/3/10" 

Thu  9/30/10 
Thu  9/30/10 
Thu  9/30/10 
Thu  9/30/10 
Thu  9/30/10 
Thu  9/30/10 
Thu  9/30/10 
Thu  9/30/10 
Thu  9/30/10 
Thu  9/30/10 
Thu  9/30/10 
Thu  9/30/10 
Thu  9/30/10 
Thu  9/30/10 
Thu  9/30/10 
Thu  9/30/10 
Thu  9/30/1 0 


KNOWLEDGE  MANAGEMENT  REPOSITORY  (KMR) 

For  CLINICAL  DECISION  SUPPORT  (CDS)  and  PROOF  OF  CONCEPT 
For  AUTOMATED  CLINICAL  PRACTICE  GUIDELINE  (aCPG  )  EXECUTION 

WITHIN  AHLTA 


Deliverable 

Resource 

Projected 

Date 

Delivery 

Delivered 

Date 

AIM  #1  -  Engineering  Documentation 
a)  Requirement  and  Analysis  and  Project  Plan 

1 

Project  Documentation  and 
Engineering  Plans 

la 

Project  Plan 

Patricia  Price 

08/26/2009 

09/30/2009 

lb 

Deliverable  Table 

Patricia  Price 

09/30/2009 

09/30/2009 

1c 

Engineering  Plan 

•  Release  1 

SOADEX 

11/13/2009 

•  Release  2 

SOADEX 

02/26;/2010 

•  Release  3 

SOADEX 

06/1 1/2010 

•  Release  4  -  Final 

SOADEX 

09/30/2010 

2 

Functional  Requirements  and 

Use  Cases 

SOADEX 

06/05/2009 

06/05/2009 

Academic  Review 

SOADEX 

1 0/ 1 5//2009 

AIM  #1  Engineering  Documentation 

b)  System  Architecture,  Technical  Design  and  QA  Plan 

3 

System  Design  Specification 

SOADEX 

08/14/2009 

08/14/2009 

Academic  Review 

SOADEX 

1 1/14/2009 

D 

User  Documentation 

KMR  Team 

02/26/2010 

1 

System  Test,  Integration  and 

QA  Plans 

SOADEX 

11/25/2009 

6 

Metadata,  Terminologies  and 
Value  Sets 

ASU 

I1/30//2010 

AIM  #2  -  Implementation  of  the  KMR  and  CDS 

Infrastructure 

7 

KMR  Repository  and  Guideline  Content  Management  System 

KMR  Team 

02/12/2010 
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Rule  and  Guideline  Runtime  Engine 

KMR  Team 

01/15/2010 
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9 

System  Administration  Portal  and  Performance  Monitoring  Tool 

KMR  Team 

12/24/2009 

10 

Point  of  Care  CDS  Tools  for  AHLTA 

•  MedAlert 

>  Release  1 

>  Release  2  -  Final  Release 

•  Milestone  Editor 

V  Release  1 

>  Release  2  -  Final  Release 

•  Patient  Portal 

>  Release  1 

>  Release  2  -  Final  Release 

•  Mobile  Tools 

V"  Release  1 

>  Release  2  -  Final  Release 
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1 0/30/2009 
02/12/2010 

03/19/2010 

08/20/2010 

04/02/2010 

06/25/2010 

04/16/2010 

09/17/2010 

11 

Guideline/Rules  Workbench  and  Authoring  Tools 

•  Guideline/Rules  Workbench 

>  Release  1 

>  Release  2  -  Final  Release 

•  Milestone  Editor 

>  Release  1 

>  Release  2  -  Final  Release 

•  Community  Portal 

>  Release  1 

>  Release  2  -  Final  Release 

KMR  Team 
KMR  Team 

KMR  Team 
KMR  Team 

KMR  Team 
KMR  Team 

12/1 1/2009 
01/2920/09 

03/19/2010 

09/20/2010 

05/28/2010 

07/09/2010 

AIM  #3  -  Development  of  Executable  Guidelines 

fl 

Content  and  Executable  Clinical  Guidelines  forTBI,  PTSD,  and  Diabetes 

ASU 

03/01/2010 

■ 

AIM  #4  -  Development  of  Executable  Guidelines 

13 

Academic  presentation  &  demonstration  of  runtime  deliverables 

ASU 

03/01/2010 

AIM  #5  -  Comparative  Research  &  Academic 
Publication 

14 

Academic  review  of  current  CDS  'state  of  the  art' 

ASU 

03/01/2010 

15 

Academic  panel  discussion  on  future  state  CDS  requirements 

ASU 

11/15/2009 

16 

Academic  review  of  completed  KMR  Project 

ASU 

09/30/2010 

17 

Academic  outcome  &  usability  evaluations 

ASU 

09/30/2010 
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